# Planning Poker and Estimation: Why Teams Estimate and When They Can Stop

Author: Marin Niehues, Niehues Consulting · Published: 2024-08-15 · Delivery & Steering
Source: https://www.niehuesconsulting.de/en/blog/planning-poker-estimation/

Planning Poker is an estimation technique in which a team rates effort with face-down cards and discusses the differences, and it pays off where that discussion exposes hidden assumptions. Where a team cuts its work into items of similar size and holds throughput data, counting finished items gives the more reliable forecast. Executives therefore need a rule for when estimating creates value and when it only costs time.

This article explains how Planning Poker works, what research says about estimates, and the criteria by which a team keeps estimating or gives it up. It closes with a calculation for forecasts from throughput that works without story points.

**Estimate so that someone can take a decision about sequence, commitment or investment. Where no decision hangs on the estimate, it merely ties up team capacity.**

## How does Planning Poker work?

In Planning Poker each team member rates the effort for a backlog item with a face-down card, all cards are turned over at the same time, and the team discusses the differences until the estimates converge. James Grenning described the technique in 2002, and Mike Cohn popularised it through his 2005 book on agile planning. The deck follows a sequence with widening gaps, usually 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, because large estimates are imprecise and the gaps reflect that honestly.

The procedure has four steps. The product owner explains the item, the team asks questions, everyone picks a card in secret, and after the reveal the highest and lowest estimators explain their assumptions. Then the team estimates again. The value of the technique arises in the conversation, because the person who plays a 3 and the person who plays a 13 usually have different things in mind: one thinks only of the build, the other of testing, coordination and a link to a legacy system.

The unit is usually story points, a relative measure of size that combines complexity, volume and uncertainty. Relative means that an item of 8 is roughly twice as large as one of 4, regardless of how many hours the team needs. The sum of points completed in a sprint gives the velocity the team plans with. Scrum does not prescribe the technique: the 2020 Scrum Guide makes the developers who do the work responsible for sizing and leaves the method open.

## What does research say about team estimates?

Research shows that group estimates with discussion are less optimistic than the average of independent individual estimates, although they are not more accurate in every comparison. Moløkken-Østvold and Haugen introduced Planning Poker in one software project for half of the tasks and had individual experts estimate the remaining tasks. In 2007 they reported similar estimation accuracy for both groups. In a 2008 follow-up study with Benestad, the group estimates for the same tasks were less optimistic than the average of the individual estimates and, on the authors' error measure, more accurate.

A second finding concerns anchoring. In 2005 Aranda and Easterbrook asked participants to estimate the duration of a software project. The project description quoted a manager's guess of about two months for one group and about twenty months for a second, while a control group was given no figure. The estimates followed the stated anchor clearly. The practical consequence is that anyone who names a number before the vote shifts the result, which is why the cards stay face down. A third finding, the planning fallacy described by Kahneman and Tversky, covers the tendency to plan projects too tightly although similar projects have run longer in the past. Estimates alone do not remove it, and historical data corrects it.

These findings lead to a sober assessment: the conversation is the secure benefit of the technique, and the number is so only to a limited degree. Teams that use Planning Poker to align knowledge get a good deal for the effort. Teams that use it to derive dates for third parties additionally need a comparison with actual delivery times.

## When is estimating worthwhile, and when can teams stop?

Estimating is worthwhile when a decision hangs on the estimate, and a team can stop when it cuts its work evenly and uses throughput data for forecasts. The criteria help with the classification.

**Estimate or count throughput**
Criterion | Planning Poker and story points | Counting finished items (throughput) | With Niehues Consulting
New team or new product | Suitable: the discussion clarifies assumptions and terms | Unsuitable: there is no data | Start with estimates, collect data from the first sprint
Items of similar size | Little added value | Suitable: counting is enough | Cut items into a few sizes
Commitment to third parties, such as date or price | Only with a check against actuals | Suitable: forecast with probability | Derive commitments from throughput data
High uncertainty in content | Suitable for clarification | Limited | Clarify first, then count
Stable team with several weeks of throughput data | Effort rarely justified | Suitable | Replace the estimation round with refinement
Comparison across teams | Unsuitable: points are team specific | Suitable if the definition of done is the same | Agree a shared definition of done

The table shows that giving up estimation need not be dogma. The movement known as NoEstimates, publicised from 2012 by Woody Zuill and others, argues that teams working with small items of similar size can save the effort of estimation rounds. That holds under conditions: the items must be small, the flow stable, and there must be data on actual delivery. The article on [delivery forecasts with Monte Carlo simulation](/en/blog/delivery-forecasting-monte-carlo-simulation/) describes how commitments arise from such data.

## How can a team forecast without story points?

A team can forecast without story points by counting how many items it completes per week and dividing the backlog by that throughput. The calculation is short, and the following example is illustrative.

1. Record throughput: over the last twelve weeks the team completed between 5 and 11 items a week. The typical value, the median, is 8.
2. Count the backlog: the delivery requires 60 items, all cut to roughly the same size.
3. Calculate the typical case: 60 divided by 8 gives 7.5 weeks.
4. Calculate the cautious case: using the value the team reached or exceeded in nine out of ten weeks, here 5 items, 60 divided by 5 gives twelve weeks.
5. Phrase the commitment: "Normally in eight weeks, with high probability in twelve." Executives receive a range with weight and a statement about risk.

The calculation has preconditions. The items must be of similar size, otherwise one giant item distorts the average. The backlog must stay stable, because new items extend the time, and the team must limit its work in progress so that lead times do not run away. The article on [limiting work in progress](/en/blog/limit-work-in-progress-deliver-faster/) shows the effect. For the view on capacity and commitments, the article on [capacity planning in agile teams](/en/blog/capacity-planning-agile-teams/) is the natural complement. And when several initiatives compete for the same team, the sequence belongs in the leadership's decision, for which the method of cost of delay provides a basis.

**Running Planning Poker well**
- Before the round, items are clarified far enough that questions can be answered in minutes.
- Cards stay face down until everyone reveals together, so nobody is anchored.
- The highest and lowest estimators explain their assumptions first.
- If no agreement emerges after two rounds, the item is clarified or split.
- Items above 13 points are broken down before planning.
- The team regularly compares estimates with actual lead times.

## What mistakes do teams make when estimating?

Teams make three main mistakes when estimating: they convert points into hours, they compare velocities between teams, and they treat the estimate as a commitment. Converting points into hours gives a relative measure false precision. Comparing velocities rewards generous estimating, because a team can raise its velocity through higher point values without delivering more. And treating estimates as commitments turns an assumption into an obligation and creates pressure that worsens the quality of the estimate itself.

At programme level another pattern appears: estimates are needed for dates before requirements are clarified. Early clarification and joint planning of dependencies help here, as the article on [big room planning](/en/blog/big-room-planning-dependencies/) describes.
## Planning Poker and estimation with Niehues Consulting

[Niehues Consulting](/en/) is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues works as delivery manager, project manager and product owner and builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. How a team arrives at reliable commitments is part of delivery management: the team decides which technique makes effort visible, and responsibility for the forecast lies with management.

The approach follows the Niehues Delivery Model with its three phases of Understand, Build and Introduce. Two of its test questions matter for estimation and forecasting: Who decides, who delivers, who uses? What is the baseline, and how do we measure success? The entry point is a free initial consultation of 30 minutes, which you can arrange via the [contact page](/en/#kontakt).

**Conclusion**
Planning Poker gets teams talking about assumptions and suits new teams and unclear content. For reliable commitments to third parties, throughput data and small items are enough in the long run. Whoever estimates does so for a decision, and whoever cannot name a decision saves the round.

**Sources**
- Schwaber, Sutherland: The Scrum Guide, 2020
- Moløkken-Østvold, Haugen: Combining Estimates with Planning Poker, An Empirical Study, Australian Software Engineering Conference (ASWEC), 2007
- Moløkken-Østvold, Haugen, Benestad: Using Planning Poker for Combining Expert Estimates in Software Projects, Journal of Systems and Software, 2008
- Aranda, Easterbrook: Anchoring and Adjustment in Software Estimation, ESEC/FSE (European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering), 2005
- Kahneman, Tversky: Intuitive Prediction: Biases and Corrective Procedures, 1979
- Cohn, Mike: Agile Estimating and Planning, book, 2005

## Frequently asked questions

### What is Planning Poker in agile?

Planning Poker is an estimation technique for agile teams in which everyone rates the effort of an item with a face-down card and the cards are revealed together. Differences are discussed until estimates converge. James Grenning described the technique, and Mike Cohn spread it.

### What are story points?

Story points are a relative measure of an item's size that combines complexity, volume and uncertainty. An item of 8 points is roughly twice as large as one of 4. Points apply only within one team and cannot be converted into fixed hours.

### Why does Planning Poker use Fibonacci numbers?

Planning Poker uses a sequence with widening gaps, modelled on the Fibonacci numbers, because estimates become less accurate as items grow. The difference between 20 and 21 would be false precision, while the difference between 13 and 20 is a real decision. The deck forces the team to commit to coarse steps.

### Is estimation mandatory in Scrum?

Estimation is not mandatory in Scrum. The 2020 Scrum Guide gives the developers responsibility for sizing and names no particular technique. Teams may choose story points, T-shirt sizes or counting items.

### How accurate are team estimates?

Group estimates are less optimistic than the average of independent individual estimates when participants vote face down and discuss differences. Studies show no consistently higher accuracy than individual experts achieve. A comparison with actual lead times remains necessary.

### What is team velocity?

Velocity is the sum of story points a team completes in a sprint. It is used to plan the next sprint and should not be compared across teams. Rising velocity means more delivery only if the definition of done stays unchanged.

### What is an alternative to story points?

The usual alternative is to cut items to similar size and count how many are finished per week. The backlog divided by this throughput gives the forecast. The range of weekly values yields a commitment with a probability.

### What is the NoEstimates movement?

NoEstimates is a movement, publicised from 2012 by Woody Zuill and others, that questions the value of estimation rounds. It proposes small items of similar size and forecasts from the number of completed items. It works where flow is stable and delivery data exists.