Story points and planning poker, without the folklore

Ask a developer how long a task will take and you will usually get a confident number that turns out to be wrong. Ask the same developer whether this task is bigger or smaller than the one finished last week, and the answer is quicker and a lot more reliable. Story points are built on that difference.

What a story point is

A story point is a number a team gives to a piece of work to show how big it is compared with other pieces of work the team has seen. It is deliberately not a measure of time. The Agile Alliance's history of velocity notes that story points became the most widespread unit of estimation, displacing "ideal weeks". The idea is to size stories relative to each other, and then use what the team has actually finished to see how much fits in a Sprint.

The mechanics are simple. To size a new story, you look for a similar one the team has already done, and give the new one the same score. A team usually works with a small set of values, such as 1, 2, 3, 5 and 8, a Fibonacci-style sequence. The reasoning behind the widening gaps is that the larger the item, the less precisely anyone can judge it, so false precision is discouraged. A useful convention, though not a rule, is to treat the largest value as "too big", a signal to split the story before it is planned.

Three things follow from this.

• Points belong to the team. There is no universal "5". Each team calibrates its own scale, which is why comparing teams by points makes no sense. The SBOK® Guide says it directly: the story point calibration is different for each team, so the number completed cannot be used for comparison across teams.
• Points include more than effort. A story can be large because there is a lot to do, or because nobody knows how to do it, or because it touches fragile code. SBOK describes assigning a value from an overall assessment of size, with consideration for risk, effort and complexity.
• Points are only useful once you have history. The first Sprints are guesses. After several, you can see how many points the team tends to finish, which is what velocity records.

Who estimates

The Scrum Guide is specific: the Developers who will be doing the work are responsible for sizing. The Product Owner may influence them by helping them understand and select trade-offs, but the number is not theirs to set. This matters in practice. When a manager or a Product Owner reduces an estimate because it is too high, the team learns that its estimates are negotiable, and stops giving honest ones.

How planning poker works

Planning poker is a way of collecting estimates that stops the loudest voice from setting the number. The Agile Alliance describes the sequence.

1. The Product Owner briefly states the intent and value of a story, and the team asks questions.
2. Each Developer silently chooses a card showing their estimate and places it face down.
3. When everyone has chosen, all cards are turned over together.
4. The people with the highest and lowest estimates explain their reasoning.
5. After a short discussion, the team plays another round, and repeats until the estimates converge or the team agrees that more discussion is needed.

Choosing in private and revealing together is the point. If the most senior developer says "that's an 8" first, everyone else adjusts. Cards remove the anchor.

A round, illustrated

Here is an invented example. A team of four Developers is estimating "A parent can cancel a booking and get a refund".

Round one: the cards show 3, 3, 5 and 13.

The developer who chose 13 explains that refunds go through the payment provider, the team has never used its refund endpoint, and the story says nothing about partial refunds. The developer who chose 3 admits they had assumed the provider's dashboard could be used manually. Those two sentences are worth more than the numbers.

The Product Owner clarifies that refunds are always full, and that manual handling is acceptable for the first release. Round two: 3, 5, 5, 5. The team settles on 5, and writes the refund-provider unknown into the story as a note.

Nobody had to win the argument. The disagreement was resolved by finding out what each person knew.

What the Agile Alliance warns about

One pitfall is treating convergence as an obligation. If the team forces everyone to agree on a single number, it can erase the most useful information in the exercise, which is the degree of uncertainty shown by a wide spread in the first round. A 2, a 5 and a 13 on the same story is data. It says the team does not yet understand the work, and the right response is often to split the story or to learn something before planning it.

Common mistakes

• Converting points to hours. "One point is half a day" turns the scale back into time, and the main benefit is lost. If you need hours for a particular reason, estimate hours; do not disguise them.
• Estimating everything up front. Only the items near the top of the backlog need sizes. Items far down will change, and effort spent sizing them is likely to be wasted. This is part of refinement.
• Letting estimates drift. If a team's idea of a 3 slowly grows, its historical numbers stop meaning anything. Keep a few reference stories that everyone remembers.
• Reading points as value. A story of 13 points is not more valuable than a story of 2. Size and value are different questions, and only the Product Owner answers the second.
• Counting unfinished work. A story that is 90 per cent complete earns no points. Work that does not meet the Definition of Done is not part of the Increment.

Other ways to estimate

Planning poker is one of several group techniques. SBOK describes four for user stories: Wideband Delphi, planning poker (which it calls a derivative of Wideband Delphi), Fist of Five, and affinity estimation such as T-shirt sizing. The last is fast for a big pile of stories: the team places them on a wall in order of relative size, in silence first, and then discusses the placements. Choose the lightest technique that gets people talking about the work. Some teams skip estimating altogether and count the number of items finished per Sprint, which works when items are broadly similar in size.

How to practise it

The only way to get good at estimating is to do it, be wrong, and talk about why. In the simulator the team estimates a real set of stories, and the scorecard shows how those estimates compared with how the work actually went.