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 suggests 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 I believe most of the attendees would be tired and lose their focus – then the meeting wouldn’t be fun anymore.
We tried better preparation to reduce meeting time. We let each individual spend more time on reading through the requirement to reduce the length of the Q&A session and also setup meeting rules to make sure the discussion (sometimes debates) are in good order, but the Sprint Planning 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 to the Agile Estimating 2.0 approach at the Scrum Gathering in Shanghai on April 19, 2010. This new estimating approach 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 participates in the planning 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 on 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, for example 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. The following article describes the approach in detail. Perhaps you might also want to give it a try.
http://properosolutions.com/wp-content/uploads/2010/05/agile_estimation_2.0-for-pdf.pdf
Seems reasonable,we will try following plan meeting