Estimation Game (1)

Whereas Planning Poker works very well for estimating a Sprint or Release while the team is up and running, it is less useful for an early project estimate. It is hard to get a good feel for the size of a project at the beginning of a project, as the team has not established a measure yet. Moreover, early in a project we don’t have the level of information needed to do a meaningful Planning Poker session.

For estimating Use Cases or Epics in an early stage (before they are detailed) we use an aproach we call the Estimation Game. It supposes that Use Cases or Epics have been identified and have a brief description. In this post we share our experiences in applying this game. In the Estimation Game the team, users and other stakeholders cooperate to estimate the Product Backlog together.

The Estimation Game – Basic Version

To get early estimates on a project we invite stakeholder representatives and the members of the Scrum team for an estimation game. Have the stories ready, preferably on cards or stickies so that you can easily move them around on a board. Initially, these stories are on a stack, ordered by business value or some other form of prioritization so that the highest priority story is on top.

All participants stand in front of a board which looks like the one in Figure 68.

Figure 68 : Estimation Board basic version

When it is your turn as a participant you do either of these things:

1. Estimate a new story from the stack by placing it in a column on the estimation board and explain your estimate to the group;
2. Change an estimate by moving a story from one column to another and explain to the group why you think this estimate is more appropriate;
3. Add a new story to the stack and explain why you think it is needed.

Stop adding stories to the estimation board some 15 minutes before the end of the timebox for this meeting (preferably two hours) has been reached but continue changing estimates. The highest priority stories should be on the board by then and a new planning meeting can be scheduled if needed to estimate the remaining stories on the stack. The game is over when all stories are on the board and/or none of the participant feels the need to relocate any more stories.

If a story is ping-ponged between two locations three times, take it from the board, mark it and place it at the bottom of the stack. This story needs more investigation before it can be properly estimated. Stories in the “?/XXL” column should also be investigated more, be broken down into smaller stories or labeled as Epics that will be broken down later in the project.

This process makes estimation very concise and orderly. People have to await their turn to add or move a story, and they have to explain their actions to the group, furthering a better shared understanding of the stories.

Expect stories to be split up or joined. This may be seen as choices the participants have during their turn, but in our experience, it is not necessary to state this as a rule. Participants will spontaneously do this when needed.

A very important advantage of doing an estimation game with stakeholders is that they can share their view on the stories and hear why some stories are hard to build while they seem simple from a user perspective. Making estimation a joint effort creates a shared ownership of the estimates. If stories turn out to be heavier later in the project as a result of added features not mentioned during the early estimation session, the impact is more easily accepted by the business.

This is part 1 of 2 of a post on early estimation in Agile projects. To this end we introduce the Estimation Game. The second part of this post described the Round Trip Verson of the Estimation Game.