Agile Estimating 2.0

Planning poker is a widely accepted estimating technology which is being used in almost all the teams in Perficient GDC. It “combines expert opinion, analogy, and disaggregation into an enjoyable approach to estimating that results in quick but reliable estimates” (Agile Estimating and Planning, Mike Cohn).
However, we found that sometimes this poker game takes quite a long time to play, especially when the team is big. Ken Schwaber figured out in his book Agile Project Management with Scrum that the Sprint Planning session should be time-boxed to 4 hours, but practically if a meeting lasts 4 hours long I believe most of the attendees would be tired up and lose their focus – that is not fun anymore.

We tried to do better preparation to reduce meeting time. We let each individual spend more time on reading through the requirement to reduce the length of Q&A session, we also setup meeting rules to make sure the discussion (sometimes debates) are in good order, but the meeting still takes time. Imagine that there are 15 User Stories on our backlog and 10 team members sitting together in the meeting, it’s quite common that those 10 people need to consume 5 minutes to finish one round of discussion before they make a decision, and in order to come up with the estimate for one User Story it’s not unusual to have 2 – 3 rounds of discussion. Thus just the time we spend for playing the planning poker can easily exceed 2 hours.

This has been bothering us for quite a long time until Brad Swanson and Björn Jensen introduced us the Agile Estimating 2.0 technology at Scrum Gathering Shanghai, April 19, 2010. This new estimating technology is also a combination of expert opinion and analogy, and it also uses Fibonacci numbers, but it is significantly less time consuming.
The first step is to have the PO introduce every User Story to the team, making sure there is no requirement related questions before we estimate.
Then the whole team participate the game. There is only one single rule - one person at a time to place one Story Card on the white board with a certain order: smaller on the left, larger on the right, similar sized ones are grouped together in one vertical pile. The whole team moves the Story Cards in turns over and over until the entire team comes to an agreement to the right order.

The third step is to assign Story Points to each User Story or story pile. In our team we prefer to use team voting to decide which Fibonacci number goes to which User Story.
And we still have the last step – use different colors to represent different aspects that are impacting the estimates, and rethink if the estimates should change. E.g., we make RED stands for those User Stories which could not be covered by automated testing, thus for those red User Stories we might consider putting larger numbers for their estimates, because over time we might have to put more effort on the manual regression testing.

We’ve played this game multiple times, and we’re quite happy with the result. The team is more confident with the estimation accuracy, and it takes only ½ the time we spent before. Read the below article and you might also want to give it a try.