It is one of the most reliably recurring scenes in agile practice, and it comes up on professional forums every few weeks. A team is refining the backlog. The tech lead — or worse, the Scrum Master — looks at an item and says “that’s a five.” Nobody disagrees. The number goes in the field. Everyone moves on, slightly relieved that refinement finished early.
Six weeks later the sprint misses, and the retrospective concludes that the estimates were bad. They probably were. But the estimate was not the failure — it was the symptom. The failure was who produced it.
The short answer, and the reason behind it
The people who will do the work estimate the work. In Scrum terms that is the Developers — the whole group, not a delegate. Not the Product Owner, not the Scrum Master, not the manager who used to write code, not the architect who designed the thing three years ago.
That rule gets taught as a matter of fairness or team empowerment, which makes it sound like an HR preference and gets it quietly ignored on busy teams. The real justification is colder than that: an estimate is a claim about information you may not have.
When the tech lead says “five,” they are pricing the work as they would do it — with their context, their familiarity with that subsystem, their mental model of what could go wrong. If the person who picks the ticket up next Tuesday has none of that, the five was never an estimate of the actual work. It was an estimate of a different piece of work performed by a different person.
The disagreement is the product. The number is a by-product.
This is the part that gets lost when estimation is delegated for speed. The value of a group estimate is not the average — it is the moment when one person says three and another says thirteen.
That gap always means something specific, and it is almost always one of three things: the two people are imagining different scope, one of them knows about a complication the other does not, or one of them has done this before and the other has not. Every one of those is worth more than the estimate. It is a scope clarification, a hidden dependency, or a knowledge gap — surfaced for free, in a meeting you were already holding.
Techniques like planning poker exist to force that gap into the open, which is why simultaneous reveal matters. It is not a ceremony for its own sake; it is a device to stop the first number spoken from becoming everyone else’s answer. When one person estimates alone, the disagreement never happens, and the information it would have surfaced stays hidden until it shows up as carryover.
Three patterns worth naming
- The expert anchor. The most senior person speaks first and everyone converges on their number. The estimate is now one person’s opinion with a quorum attached. Fix: reveal simultaneously, and let the most junior person explain their reasoning first.
- The absent estimator. The item is sized by whoever attended refinement, then assigned to someone who was not there. Fix: treat a large gap between estimator and assignee as a re-estimation trigger, not a scheduling detail.
- The manager in the room. Estimates drift downward when someone who signs off on promotions is watching. This is rarely deliberate and almost never admitted. Fix: if leadership needs to observe refinement, they observe — they do not vote, and they do not react to numbers.
None of these are exotic. They are the ordinary failure modes of a meeting that everyone wants to finish early. This is a different problem from the one covered in why story points miss, which is about the accuracy of the scale itself, and from the no-estimates debate, which questions whether to size at all. Both of those assume the estimate came from the team. Here, it did not.
What ownership buys you downstream
A sprint commitment inherits whatever authority the estimates behind it had. If the team sized the work, the commitment is a genuine forecast that the people doing the work stand behind, and they will tell you early when it stops being true. If one person sized it, the commitment is that person’s opinion, and everyone else is a bystander to a promise made in their name. Bystanders do not raise the alarm on day four. They report it on day nine.
Practically, three habits carry most of the benefit. Estimate as a group and reveal at the same time. Keep two or three reference items the team agrees on, so “five” means something stable rather than drifting quarter by quarter. And when the discussion exposes a real unknown, write it into the ticket — the question that surfaced it is more durable than the compromise number you settled on.
Tooling helps by making the estimate visible against the thing it has to fit. Backlog Refinement, Sprint & Capacity Planning for Jira keeps refinement and capacity on one screen, so a team can see immediately whether the numbers they just agreed on fit the people actually available — which is usually the moment an optimistic estimate gets challenged by someone who would otherwise have stayed quiet.
For how estimation fits the rest of the ceremony, see our complete guide to sprint planning in Jira, the sprint planning meeting agenda, and story points versus hours if you are still deciding what to estimate in.
Key takeaways
- The people who will do the work estimate the work — the whole group, not a nominated expert.
- The justification is informational, not political: an estimate made by someone else prices different work done by a different person.
- Disagreement between estimates is the valuable output. It reveals mismatched scope, a hidden complication, or a knowledge gap.
- Watch for the expert anchor, the absent estimator, and the manager in the room — all three quietly convert a team estimate into one opinion.
- A commitment inherits its estimates’ ownership. Work sized by one person produces bystanders who report problems late.
- Reveal simultaneously, keep stable reference items, and write the unknown into the ticket rather than into the number.
Frequently asked questions
Should the Scrum Master estimate story points?
No — unless they are also doing the work, which is unusual. The Scrum Master’s job in estimation is to make the conversation happen well: keep the reveal simultaneous, notice when one voice is anchoring the room, and stop the session converging on a number before the disagreement has been explained. A Scrum Master who supplies estimates has taken over the very discussion they are there to protect.
What if only one person on the team can do the work?
Then that person’s estimate is the best available number, and you have found something more important than an estimate: a single point of failure in your delivery. Size it with them, but treat the discovery as the real output — knowledge concentrated in one head is a capacity risk long before it is an estimation problem. Pairing or documentation on those items will do more for your predictability than any refinement of the number.
2 Comments
Leave your reply.