This week I coached a product team in Shanghai consisting of 3 Scrum teams (about 8 people per team) working on a single backlog. The challenge: how to estimate a backlog of 200 items for the team’s first release planning session, without taking all day?
The solution: Dynamic Team Estimation
I’ve blogged previously about Steve Bockman’s Team Estimation Game. This is a great alternative to planning poker which I’ve found easier for teams to understand, and much faster than planning poker. My colleague Björn Jensen and I presented some adaptations to the Team Estimation Game at the 2010 Shanghai Scrum Gathering that we call Dynamic Team Estimation. (Our presentation is available on the Resources page under Agile Estimating 2.0). We used Dynamic Team Estimation in this case and it worked very well.
First, we considered having the three teams divide the backlog and have each estimation their own subset of items. The teams, however, preferred considering the whole backlog together. Since it wouldn’t be effective to have 20+ people all trying to estimate at the same time, we asked each team to select 3 representatives who would do the estimating, being sure that we had a good cross-section of skill sets included.
Our team of 9 estimators plus Scrum Masters and Product Owner gathered in a room with a large table. Since the teams were in their 3rd sprint, we started by laying out the completed user stories on the table based on their size to serve as our basis – small items on one end of the table, large item at the other end. These stories already had story point values. The product owner printed the backlog items on half-sheets of paper and brought them in a stack ordered by priority. We laid out the top 10 or so backlog items on one end of the table and began by using the structured rules of the Team Estimation Game. One person at a time could estimate one item placing it on the table according to size, or could choose to change an estimate made previously. Players proceed in round-robin fashion, with each player explaining his or her rationale. Other players are allowed to ask clarifying questions, but not to debate the estimate – they will have that chance on their own turn. Rather than proceed in strict priority order, we allowed each player to choose any story from the 10-or-so top-ranked items we set out.
Before we could even get one time around the table, the team was wanting to bend the rules. They were having discussions about each item, and while one person was placing an item, others were looking at the yet-to-be-estimated items. We asked them to remember the rules, and to get around the table at least one time before we considered relaxing the rules.
After the first round, we asked the team if they wanted to relax the rules and instead use Dynamic Team Estimation. They quickly agreed and immediately swarmed the table. Pairs and small groups had discussions about out items, and 2-3 items were under consideration concurrently at most times. We asked the team to follow one rule now: whenever someone estimated an item (by placing it on the table), he/she would get the whole groups’ attention and explain the rationale for the estimate; this gave everyone a chance to provide input or disagree. This was important – without it, estimates might not be considered by the whole team.
We split the session into pomodoros (25 minutes of work followed by a 5-minute break). During each pomodoro, the teams invited a few other members to attend so that everyone could observe the process and contribute if needed. The Product Owner answered questions and clarified the user stories.
After 3 and a half pomodoros, the team finished estimating 200 items with smiling faces. Just a few days earlier, many team members said they didn’t think they’d be able to estimate most items, and no one (including myself) thought we could do it in less than 2 hours. Success!
The backlog is not posted on a large wall, arranged by sprint based on the team’s velocity and estimates. The whole team now has visibility into the scope of the project and can use this tool for look-ahead planning (as described by Mike Cohn).
{ 5 comments }
