Why does planning poker work so well?

Using a card game like poker for planning a software project 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 initial estimates for each item, then you can make statistical claims. Useful claims might include:

• 95% of 5 point stories were completed within 4 weeks.
• 99% of medium stories took less than a week.
• Several 1 point stories were all delivered in 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 simpler, not 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.

Who invented planning poker and why so many names?

Planning Poker was invented by James Grenning after a particularly slow meeting. The team was bored and had nothing to engage with, while just two team members discussed an estimate. They finally kept the same estimate they had before heading down this rabbit-role 20 minutes earlier.

The game was popularised by Mountain Goat Software’s Mike Cohn in his book Agile Estimating and Planning. He also trademarked the name “Planning Poker” and requires teams to use his modified sequence of numbers which is optimised for reporting. Many other names are used, for example, pointing poker is at least as popular in the United States. Scrum teams often call it Scrum Poker, because they are producing Sprint forecasts.

We use the name “Estimation Poker” because we do not sell decks with the whole of the Planning Poker sequence, offering more player-sets per deck instead. We have optimized our decks for fast estimation during the planning session, rather than reporting afterwards. Using the raw Fibonacci series ensures each card has a consistent relationship to the cards that come before it in the sequence. We believe this makes life easier for estimators.

This level of non-conformity is a sign of large and diverse communities taking an interest in the game and bringing with them their own perspectives. This is a sign of the game’s popularity and increasing importance in project delivery best-practices.