We seem to reach consensus much faster…
In case you missed our Summer 2014 release announcement, Estimably™ is a free, poker-style agile estimation tool (game) within VersionOne TeamRoom™ that allows a team to easily participate in story estimation exercises no matter where they work. One of VersionOne’s development teams was an early use case, and discovered first-hand the value of a good estimation tool.
The team is called openAgile, and is VersionOne’s most distributed team. Led by Josh Gough, openAgile has people in Midtown Atlanta, in the hour-north-of-Atlanta suburb, Alpharetta, in the 12-hour-flight-south-of-Atlanta city of Paraná Argentina, and occasionally at home; yet, the team still finds ways to pair program and to be available to each other for helping out and answering questions.
I’ve spoken with openAgile team members who say the following collaboration tools are part of the formula for success with distributed agile teams:
- VersionOne (of course)
- Google Docs
Today I’ll focus on Estimably and give you the story from inside our dev team on how this tool was created, how it has helped our teams, and how it can help yours reach better consensus, faster – particularly with distributed teams – during story estimation.
Before Estimably, the openAgile team was trying to put estimate values directly onto stories in VersionOne while discussing it in a GoToMeeting. In the words of Amitai Romanelli, the team’s software-engineer-in-test, “We would discuss items and throw out ideas, after which the product owner would take the comments and suggest a number and seek agreement.” Josh characterized the process by saying, “One or two people closest to an item spoke up and basically dominated the estimate. The loudest people in the room had the most influence over the outcome. It was a problem because we focused on who, rather than what and how.”
Sometimes the loudest people in the room were those who were really involved on an item. Sometimes the loudest people in the room were those who knew the most about the technology. And sometimes the loudest people in the room were hosting the meeting. Even if the bias varied, the inconsistency in the process generally led to a feeling of disinterest and frustration.
Laureano Remedi, a developer on the team, expressed that, “Estimation was less participatory since only a few people who really knew the work were talking about the estimates. Conversation was focused and centered among them.” Many people on the team were feeling their participation didn’t matter – or, at most, that participation was difficult. More objectively, the team was taking an hour to get through a small set of stories without building solid, shared understanding.
They were already dealing with day-by-day context switching across multiple products. Even with uncompleted stories in a sprint, people were idle without a clear idea of what to do next. The openAgile team had started to do weekly backlog grooming sessions. As the product owner, I brought Estimably to the team to try out. Nominally, the team developing it was looking for feedback on what they were building. One of the developers, Acey Bunch, explained, “We tried it because we’re geeks. Plus, I think we sensed the need to find a better way to estimate.” Another developer on the team, Matias Heffel, described Estimably as, “a cool and very helpful tool that I could recommend to distributed teams, like ours. Without saying a word, you assert opinion with a simple, numeric vote. Even that simple vote can lead to a fruitful discussion.”
Developer Mariano Kunzi described the current agile estimation process: “The moderator picks a story and leaves it open so everybody can read it. Most of the time, it comes with a context explanation so everybody can understand what is about to be estimated. Questions are allowed, too. After that, the story is put in Estimably so each individual can vote. Once that is done, the votes are shown. When there is not consensus, people in the upper and lower extremes explain why they voted that way. When explanations are done, the votes are cast once more. If consensus is still not achieved, the moderator makes or influences an outcome.”
Valentin Plechuc, another team member, described the result as, “a more smooth process with focus on what we are looking for, in this case the estimate for just one story. Overall, story estimation is more organized, more dynamic, more participatory, and with less time wasted.” Mariano added, “The new process forces me to participate and pay attention. With Estimably, you take an active role instead of a passive one (that’s a good thing!). I also think everybody gets to state their opinions, even if it is just by voting.”
“We seem to reach consensus much faster, and everybody seems to agree with the final decision,” Acey added. “We actually accomplish what we set out to do, and our story estimates are much more reflective of what the team thinks as a whole.”
“The product owner still has a lot of influence. This is not a bad thing,” Josh said. “As the product owners refine backlog items into smaller, testable units ahead of time, they set their teams up for success and for smaller estimates. This has resulted in more cohesive workitems that have better team understanding and consensus. Overall, we feel informed, up to date, and prepared.”
Check out Estimably and tell me what you think in the comments below. If you think Estimably is something you might want to try, learn more here or make a request.
The post Inside Our Dev Team: The Birth Story of Estimably for Agile Estimation appeared first on VersionOne Blog.