Estimation in the Large By David Bulkin

This post is for those who believe that story point estimates are valuable (if you are not sure you can read the post linked here) and who have to estimate a large number of stories at one time (e.g. in Discovery / Sprint 0 or at Release Planning).  

Most teams use Planning Poker all the time, but does Planning Poker work effectively when you have 150+ stories that you need to estimate at one time?

In practice, Planning Poker is too slow when estimating large backlogs. To be more formal, I created acceptance criteria to judge a story point estimation process that you would use for an approved effort (e.g. you may want to use a different approach if you just want a rough size prior to approval):

1. Leads to a shared, common understanding, of the user story.
2. Results in an ability to create a credible release schedule across the backlog.
3. Relatively quick to use.
4. Fun, or at least not painful to use.

I didn’t list accurate story estimates as acceptance criteria. This is because I care more about a common understanding and a credible schedule across the backlog (e.g. the aggregate of the estimates are what counts, so if there are two stories that should be a 5, and one is labeled an 8, and another a 3, I am ok with that).

In any case, Planning Poker meets the top two acceptance criteria when working with small backlogs. With larger backlogs your mileage may vary because of the stress created by failing to meet the third and fourth criteria.

Planning Poker is not very fast, and when it slows down it gets painful, resulting in tension, poor estimates and lack of clarity. It also results in a large loss of time.  No wonder so many have given up on estimating!

Assuming you do want to estimate, there are approaches better suited to large backlogs.  The Team Estimation Game developed by Steve Bockman is summarized.

1. The Product Owner ranks the story cards and places the highest ranked card in the center.
2. The team arranges the story cards, left to right, in columns, by size, on a table, whiteboard, or in an electronic tool.  The leftmost column is the smallest story, the rightmost the largest.
   1. Team Members take turns.
   2. In each turn the team member can take the top story card and place it into one of the existing columns or create a new column.
   3. Or, the team member can take a previously placed card and move it.
3. After all stories have been estimated, each team member can move one card, and then the team assigns the relative scale, such as the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800), to each column.

I think the Team Estimation Game is superior to Planning Poker for large backlogs, but does it meet the acceptance criteria?

There is a tension between obtaining a shared understanding (first criterion) and being quick (third criterion). As such, I believe there are variations on this theme that are even better for large backlogs.  But, it wouldn’t be any fun if I included those variations in this post.

So, next time, we will look at some alternatives.  Until then, please write us with your thoughts and what has worked for you.