Agile estimation in Scrum
In Scrum, estimation serves two purposes. It helps the team decide how much work to take into a sprint. It also tells the business roughly when to expect a result. When estimates are used for reporting or deadlines, they stop working.
Where estimation happens in the sprint
Scrum itself requires neither points nor poker. It requires backlog items to have an estimate, and the team decides how to get it.
In practice, teams estimate in two places. The first is backlog refinement, a regular session to go through items for the next sprint or two. The second is sprint planning, where clear items are broken down into actual work.
There is no need to estimate everything. Only what will be built soon is worth sizing. An estimate for an item six months away will be out of date by then.
An estimate is not a commitment
This difference is worth repeating every time someone says “but you promised”. An estimate is what the team knew about an item when it sized it. A commitment is what the team agrees to deliver, taking holidays, support duty and everything else into account.
When estimates are treated as commitments, the team gets defensive. People pad, round up and argue about wording. The numbers go up, accuracy goes down, and planning turns into haggling.
How estimates turn into a plan
The team tracks velocity: how many points it finishes in a sprint. After three or four sprints the average and the spread are visible, and you can rely on them.
Then it is simple arithmetic. The release backlog has a hundred and twenty points, and the team finishes forty in a two-week sprint. That means three sprints, about a month and a half. This is a forecast, and it is more honest to give it as a range: “three to four sprints”.
A range is also more honest because the backlog changes. Half of what will end up in the release is not in the backlog yet. It is better to plan for that openly than to hide it in the estimates.
Who estimates
The people who will do the work. If a manager, an analyst or an outside architect sets the estimate, it becomes a quota handed down, and the team does not own it.
The product owner takes part in the round but does not vote. They explain what is needed and answer questions. Developers, testers and everyone whose work is part of “done” vote as equals.
What devalues estimation
The same mistakes happen in teams of any size.
- Estimates as a KPI. Once people are judged by a metric, they adjust it to look good.
- Comparing teams by velocity. Each team has its own scale.
- Estimating an item with no description. Blind numbers spoil the forecast for a long time.
- Rewriting past estimates to make the statistics look better.
- Estimating the entire backlog far ahead. It goes out of date before it is useful.
When you can skip the numbers
Some teams do without points. They split every item down to roughly the same size and count them (the #NoEstimates approach). The forecast is just as good, and estimation takes less time.
This works when items come in a steady flow and are similar to each other. If the backlog mixes small fixes with half-year epics, counting items is meaningless. Then planning poker is needed again.