Yves Riel has been exploring Scrum by participating as a team member, a Scrum Master and a Product Owner. He also acts as a Scrum Coach to help teams learn the Scrum methodology. Yves has actively been using Jira and GreenHopper since 2009.
Benjamin Franklin once said that there were two certainties in this world: death and taxes. I suspect that if Benjamin Franklin had been in the software industry, he would have added “estimation” to the lot. Although there are some heated debates on the value of estimation in the Agile community, I have not once been in a situation where I was able to start a project without providing first some sort of estimate. Since in my world estimation is a certainty, just like death and taxes. So our development team had one choice: get better at it. This post will cover techniques that helped us do it.
Absolute vs Relative Estimates
Let’s say that I throw you in a room with a bunch of other people and ask you to give me estimates for the heights of different buildings in this Minneapolis skyline. Your team would probably take a long time to come up with the estimates and, chances are, those estimates would be way off. Now, if instead I ask your team to take the building just in front of the highway and give it a relative size of 1. I’m sure that in just a few minutes, the team will have estimated all the buildings to be 2, 3 or 4 times bigger than the first one. So, it seems that comparing things relatively to each other is much easier than making absolute estimates. This technique, sometimes called Triangulation, is essential in Planning Poker® session.Out of sight, out of mind
As a Scrum Master, I noticed that my team eventually lost sight of previous estimates. They would estimate a user story as 2 points while other similar user stories had been previously estimated and executed at 3 points. So I started to put, on a piece of paper, a sample of previously estimated and executed user stories. I would display, in the center of the table, a page for each of the story points’ value in the Planning Poker® deck. On each page, 4 or 5 user stories matching this estimate would be listed. Now, when the team was giving an estimate, I would ask the members to validate with what was on the table. Essentially I was forcing them to use triangulation.That helped the team correct their estimates and they got more consistent in their estimation by sticking to triangulation.
The Gray Zone
I eventually started to notice that the team was struggling when estimating user stories that were not clearly one value or the other. It was as if the story was in a gray zone. So I started to sort the sampled user stories from the story that took the least time to implement to the story that took the longest time to implement. Moreover, I made sure to select user stories that were at the both ends of the spectrum for any specific point value. This would give the team a unique perspective on the transition from one story point value to the next. If they were hesitating between a 2 and a 3, they would look at the 2 point stories that took the most time to implement and then to the 3 point stories that took the least time to implement. It became easier for them to say how many points the user story that they needed to estimate really deserved.
Conclusion
By using these two techniques, the team’s estimates improved, their velocity stabilized and they were more consistently concluding their sprint by delivering what they committed themselves to. In retrospect, triangulation helped the team but it required actual data to be most effective.
Getting started with Triangulation is easy. The all-new Rekall Plugin for Jira makes Triangulating your next user story’s estimate visual and intuitive. Try Rekall for Jira and GreenHopper today!