Estimation Poker for Planning and Forecasts

Estimation Poker, popularised under the name Planning Poker, is an effective tool for relative estimation of complex empirical work, such as engineering or software development. It is a quick and efficient way to get the data you need to produce a plan.

Also known as Scrum Poker or Pointing Poker the game results in a numerical score being assigned to a product feature or deliverable, such as that described by a "user story". 

This score is the number of "story points" - a relative measure of complexity or risk - which can be fed into planning and forecasting processes.

How to play

  1. Developers are each dealt an identical hand of Estimation Poker Cards. Each card has a number from the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21 plus coffee and question mark symbols.
  2. In this context a developer is anyone who contributes to the implementation, and can include quality assurance, cyber security, user experience and operations professionals.
  3. Someone with an understanding of the feature, usually the product owner, presents the feature. 
  4. The development team then discuss the feature as much as they feel necessary. Optionally, they produce and agree a task-break down but tasks won't be estimated individually.
  5. At an agreed time, developers secretly select a card reflecting their individual assessment of the feature, how complex it is to engineer, test and deliver. If the developer does not have an estimate, or needs a break, play the appropriate card.
  6. Altogether, on count of three, the developers share their card.
  7. Unless there is already consensus, conversation should now focus on why the story is seen differently by the developers who played the highest and lowest cards.
  8. Steps 5 to 7 are repeated until there is consensus, or the team agree to invoke one of a number of strategies to resolve differences of opinion.
  9. Once there is consensus record the number of story points against the user story. Writing it on a user story card with a pen is a great start, as that record is immutable.

How long does it take?

Estimation poker is often time-boxed to keep it as short as possible, but there is also value in allowing the technical solution to be discussed thoroughly. The level of depth to go into is a trade-off decided by the teams.

Estimates are not directly valuable to a business in the way that features are. Teams should be estimating for a clear purpose, to help make a decision or verify a plan.

Once your team have discussed a feature and exchanged perspectives there is little else for them to gain. So the game should last long enough to meet the purposes of estimating but no longer than that. 

Why does estimation poker work so well?

Using a game like poker for planning might seem odd. This gamification encourages team members to think independently by asking them to reveal their score simultaneously with their peers. This avoids the cognitive bias known as anchoring and exposes situations where team members hold different information or perspectives on the work.

Influential Lean Management theory categorises estimation as waste because it does not directly deliver value. Agile practitioners therefore try to reduce the time spent producing estimates, which have a poor history of inaccuracy anyway.

Typically, conversations during the game will be focused on the perspectives that differ the most. This means that details that will not effect the estimate are less likely to be discussed and the conversation is much more efficient.

Another reason this poker game process makes planning cheaper is that it takes relative complexity as the input, rather than a complex design document that may not be accurate. There is simply too much detail to be discovered down the road, and without an implementation in-progress much of that detail is not discoverable.

Relative complexity however, is a tractable question. Only a broad outline of the solution is needed to determine this, and that outline can be produced in a fraction of the time, dramatically reducing the effort needed to produce an estimate.

What is a story point?

A story point is an abstract unit. It is not convertible to time or cost in the way that you can convert inches to centimetres. You can, however, use it as a leading indicator of the cost or time you are likely to need to achieve a goal.

If you are keeping good records of the work your teams have done, and the estimates they provided in the past, then you can make claims of a statistical nature such as 95% of 5 point stories were completed within 4 weeks. Or 99% of 3 point stories took less than a week. You can then extrapolate a typical velocity in terms of story points per man day, with a known degree of confidence.

Velocity is the term used to describe this ratio of story points to time. It is sometimes said that a team which does not know it's velocity is not doing agile.

How do story points help me forecast a release?

Once a team knows it's velocity, and has estimates for a body of work then you can make a prediction about when that work will be completed.

Let's say you need 4 features before you can launch a new advertising campaign. Your marketing team need to decide whether to tie the campaign into a sporting event in the Spring, or a music festival in the Summer.

Let us suppose:

Estimates are 5 + 13 + 3 + 8 = 29 story points

They will probably split the 13 point story to an 8 and a 5 point story, with the same total.

The team's historic velocity is at least 10 points per week.

Their record is such that 95% of the time they manged to deliver features with 10 points of complexity each week. 5% of the time they hit obstacles and performed more slowly.

The sporting event takes place in the first week of June. To meet that deadline confidently the team must be ready to start by the 1st of May.

If they are not ready to start by that date then the Marketing team may decide to tie in with the Summer music festival. Alternatively, faced with a 3 month delay  they may decide to drop one of the features and accept a smaller uplift more quickly.

For example, they may determine that the cost of running the team for more than a week does is not justified for that 13 point user story, but the team split it to a 5 and an 8 and marketing can accept just one part, or none.

Such decisions are quite easy to make with the help of spreadsheets given this level of detail. Asking the team to estimate every task and sub-task to the hour would simply delay the start date and may not result in a more accurate prediction.

Why use the Fibonacci Sequence?

The Fibonacci sequence is a series of numbers derived by adding the two prior numbers. It frequently turns up in nature, such as in the spiral form of flowers. It is named for the Italian mathematician Leonardo Bonacci, known as Fibonacci, but was first identified in India. It's use in estimation is almost arbitrary, but it's popularity has some important causes:

  • The difference between numbers increases over time. This matches the experience of developers and project leaders who know that features that are only slightly more complicated are much more likely to take longer to deliver.
  • The relationship between adjacent numbers is consistent. Developers have plenty of details to consider while estimating. If the relationship between adjacent numbers seems to change then this is confusing and burdensome. Using consistent numbers makes this simplernot harder even if they happen to look strange.
  • It is clearly unrelated to time. We have a feel for which numbers are related to time. 5 days, 52 weeks, 12 hours, 15 minutes. The Fibonacci sequence is distinct from those numbers. This makes it easier to have conversations about what story points are.

We prefer the raw Fibonacci sequence over variations as it is optimal for the process of estimating. Variations that use rounded numbers are motivated by a need for round numbers in reports, however, we favour reporting only the forecast delivery dates and doing so in units of time. We expect this to prevent comparisons of teams based on velocity, which are rarely meaningful.