At Doximity we have a large, distributed development team. From Brazil to Missouri to France, we have remote developers working in nine different time zones on roughly 15 different teams.
Though each team is free to design their own processes, they generally follow a modified scrum workflow which involves iteration planning, a.k.a. estimation. In estimation, each team member casts a vote for each story based on the amount of time and effort they believe the story requires. We use Slack as our chat application and hubot, an open source chat automation tool, to build custom chat functionality that fits our organization’s needs. To help facilitate the procedure of voting remotely, and often at different times, I have developed a plugin for our friendly hubot; Hubot Estimate.
Before the introduction of Hubot Estimate, our estimation meetings would follow this general flow. Product managers (PMs) would post stories in the team’s Slack channel, or a channel dedicated to estimation meetings. Then, while on a multi-way video call, one person would countdown from three. At that point everyone would either hold up a number of fingers or post their vote in a long-running Slack thread. We use the Fibonacci sequence voting style and points rarely exceed eight.
Almost every team has seen some difficulties with this style of voting. When voting via video, the largest issue is often that not everyone is ready at the same time. It can also be hard to tell how many fingers everyone is holding up depending on the video chat tool the team is using. For example, Google Meet cycles through participant thumbnails after more than three or so participants are in the same meeting rather than showing all of them all of the time. When voting via a Slack thread, timing is vital in order to keep voting private. If each person’s vote is a few seconds off, that vote may influence the next one. There was simply no easy way to privately vote at different times.
The primary goal of the Hubot Estimate is to solve the issue of keeping votes anonymous while enabling people to cast their vote via Slack at various times. If a junior engineer was to see the vote of a senior engineer before casting their own, they may vote closer to the score of the more experienced developer. This is an issue because the junior engineer may have more recent context with the part of the system that a story is referring to or think of complexities missed by other team members. It is best if everyone votes privately and any outliers to the median score explain their reasoning as to why their vote is higher or lower than others.
On our quarterly hack day, a day where engineers can work on any project they want outside of their team’s stories, the first version of the bot was born. It allowed users to associate a vote with a story number in Pivotal, our project management tool. The estimation meeting flow then changed. PMs began to post a list of stories before the meeting, typically a full twenty-four hours beforehand. Developers would then examine the requirements and post any related details worth mentioning. When ready, each developer would switch to their chat with the bot and post a message to cast their vote.
Then, either before or during the call for the estimation meeting, one person would ping the bot for the list of each user and what they had voted as well as include the median vote.
This solved a lot of problems but still had room for improvement.
It became obvious that having to check who has voted and print the votes during the meeting was distracting to the person in charge of pinging the bot. The next, and current, iteration of the bot solved that issue. After another hack day, we were able to fulfill several wishlist features. We added the ability to register a list of team members, as well as a Pivotal board and Slack channel associated to that team. Now, when all the listed members have cast their votes, the final scores are posted to the registered Slack channel along with a link to the story in Pivotal. The Pivotal story that is being voted upon is also updated with either the median of the votes or the unanimous vote. This has automated the entire process and has even allowed voting to completely take place independently of the video meeting.
As a result, our estimation meeting time has decreased from an hour to less than 15 minutes. The content of the meeting has also changed from gathering requirements to ironing out details and coming to an agreement on implementation.
Sample thread of actual voting taking place in a slack channel. These votes are printed and the story is updated when the final voter has cast their vote. Ultimately, this had led to reactions such as, “This is awesome…. I didn’t realize that it would just set the estimate as soon as everyone voted. Now I don’t have to babysit the discussion threads!”
Please see the npm package and GitHub page and feel free to reach out with any questions or ideas for improvements. Also note that the bot may still be used for simply casting and checking votes without the Pivotal tracker integration.
Sound interesting? We’re hiring. Apply here
Huge thanks to Bruno Miranda and Ellie Riley for editing, and Hannah Frank for the epic illustrations
Be sure to follow @doximity_tech if you'd like to be notified about new blog posts.
