Dynamic Team Estimation in Action

by Brad on May 29, 2010

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).

http://properosolutions.com/wp-content/uploads/2010/05/agile_estimation_2.0-for-pdf.pdf

{ 5 comments… read them below or add one }

James Grenning May 31, 2010 at 8:02 pm

This looks like another good way to estimate a large stack of stories. I’ve found the Planning Poker Party a effective technique to estimate a large stack of stories ad use this with teams I coach.
See it described here: http://www.renaissancesoftware.net/blog/archives/36

Lisa Crispin June 1, 2010 at 11:56 am

Interesting process. Personally I question the value of estimating 200 stories at once. How soon will they be completed? What’s the likelihood they’ll be supplanted by higher priority stories, so that the estimation was a waste of time? I guess if the organization is big enough and the stories are small enough so that they’ll be done in the next couple or three iterations, it might make sense. IME these huge product backlogs just gather dust. I like a leaner approach of only estimating and planning for the next 3 iterations max.

Brad June 1, 2010 at 9:07 pm

Lisa,
Thanks for your comments! I normally agree that 200 items is too much, but in this particular situation the product backlog is very unlikely to have significant changes. The PO needs to begin setting expectations with stakeholders, and the team itself wants a “bigger picture” view of the overall project. Overall it is providing value and didn’t take much time.
That aside, the technique is still a very effective one regardless of the number of items being estimated. It can also be combined with planning poker. After placing story cards based on relative size only (not story points), the team can used planning poker to assign a point value to each group of story cards.

Boris Gloger June 2, 2010 at 2:19 pm

Cool! Sounds like a very good approach. It is not as fast as the Magic Estimation technique that I use to teach, but has the advantage of some rationalism. I also believe that Planning Poker was good idea for estimation purpose 5 years ago, when we started to do Scrum and XP. Today I believe Planning Poker is outdated. Team members tend to discuss efforts during Planning Poker instead of giving them relative values of Size. That created the need for new group facilitation techniques as your Dynamic Team Estimation. — it is great that we find always new ways to enable teams to be more productive. — Boris

Dan Neumann January 31, 2012 at 7:47 pm

Very nice description. It certainly helped clarify your Agile 2012 conference submission. I may give this technique a try with teams I coach.

Leave a Comment

{ 1 trackback }

Previous post:

Next post: