Agile estimation in Scrum
Estimation in Scrum is not there for reporting and not there to set a deadline. It exists so the team can decide how much work to pull into a sprint, and so the business can tell roughly when to expect a result. Everything else people hang on it breaks it.
Where estimation happens in the sprint
Scrum itself requires neither points nor poker — it requires backlog items to have an estimate. How to get there is up to the team.
In practice estimation lives in two places. The first is backlog refinement: a regular session where the team looks at what will be picked up a sprint or two from now. The second is sprint planning, where items that are already clear get broken into actual work.
There is no need to estimate everything. Only what will realistically be built soon is worth sizing: an estimate for an item that comes up in six months will be stale long before anyone needs it.
An estimate is not a commitment
This distinction is worth saying out loud every time the word “promised” shows up in a conversation. An estimate is what the team knew about an item when it sized it. A commitment is what the team takes on knowing about people, holidays, support duty and everything else.
The moment an estimate starts working as a commitment, the team starts defending itself: padding, rounding up, arguing about wording. The numbers go up, the accuracy goes down, and planning turns into haggling.
How estimates turn into a plan
The team tracks velocity — how many points it takes to done in a sprint. After three or four sprints both the average and the spread are visible, and those can be leaned on.
Then it is arithmetic: the release backlog holds a hundred and twenty points, the team gets through forty in a two-week sprint, so that is three sprints, roughly a month and a half. That is not a date but a range, and it is more honest stated as one: “three to four sprints”.
A range is also more honest because backlogs move. Half of what ends up in the release is not described in it today, and it is better to allow for that openly than to hide it inside the estimates.
Who estimates
The people who will do the work. Not a manager, not an analyst, not an architect from outside — otherwise the estimate becomes a quota handed down, and the team has no relationship with it.
The product owner takes part but does not vote: their job is to explain what is needed and answer questions. Developers, testers and everyone whose work is inside the definition of done vote as equals.
What devalues estimation
The same mistakes repeat in teams of any size.
- Estimates as a KPI. A metric people are held to stops describing reality and starts describing the wish to report well.
- Comparing teams by velocity: each has its own scale, so the comparison means nothing.
- Estimating an item with no description. Numbers cast blind poison the forecast for a long time.
- Rewriting past estimates to make the statistics look tidy.
- Estimating the entire backlog to the horizon. It goes stale faster than it becomes useful.
When you can skip the numbers
Some teams do without points entirely: they split every item down to roughly the same size and simply count them (the #NoEstimates approach). The forecast is no worse and less time goes into producing it.
That works where the flow of work is even and homogeneous. If the backlog mixes small fixes with half-year epics, counting items means nothing — and planning poker comes back.