Story Points Without the Theatre: What Good Looks Like Versus What Bad Looks Like
Few practices in Scrum get distorted as fast as story points. They start as a quick way for a Developer team to compare the relative size of work and end up as a productivity scoreboard that someone outside the team reads like a stock ticker. The Scrum Guide never mentions story points at all — estimation is left to the team — yet many organizations treat the number as the point of the exercise. When that happens, you get the theatre: hours of debate, inflated estimates, and a velocity chart that measures nothing real. The technique is fine. The way it is used is usually the problem.
What the points are actually for
A story point is a relative measure of effort, complexity, and uncertainty — not a unit of time. The whole value of relative estimation is that humans are poor at saying 'this will take 6.5 hours' but reasonably good at saying 'this is about twice as big as that one.' The Developers estimate together so that the forecast reflects shared understanding, and so that the conversation surfaces hidden complexity before the work starts. The number is a by-product. The conversation is the point. In a remote-first 2021, that conversation became more deliberate — and teams that protected it estimated better than those who reduced planning to clicking a number in a tool.
What good looks like
The Developers own the estimates; no one outside the team overrides them or sets a 'target velocity.'
Estimating sparks a short discussion that exposes unknowns, dependencies, and missing acceptance criteria.
Velocity is used by the team to forecast how much to pull into a Sprint — a planning aid, not a performance grade.
Points are relative and stable; the team compares new work to reference stories everyone remembers.
When uncertainty is high, the team splits the item or spikes it rather than guessing a bigger number.
What bad looks like
Management tracks velocity as a productivity metric and asks why it 'went down,' so the team quietly inflates points.
Estimation becomes a long negotiation about whether something is a 3 or a 5, with no new understanding gained.
Points are silently converted to hours, defeating the entire purpose of estimating relatively.
Velocity is compared between teams, as if a point meant the same thing across different groups — it never does.
Carryover and unfinished work are reported as 'done' to protect the number, hiding the real state of the Sprint.
Getting the theatre out
If estimation in your team has turned into performance, a few deliberate moves usually fix it.
Keep velocity inside the team. Stop reporting it upward as a score. Report outcomes — working increments and what was delivered — not the internal forecasting number.
Time-box the estimate. If two values are being debated for more than a minute or two, pick the higher one and move on. The discussion already gave you its value.
Anchor on reference stories. Agree on a couple of well-understood past items as your 3 and your 8, and estimate everything relative to them.
Treat surprises as signals. When an estimate feels impossible, that is information: the story is too big or too vague. Split it before committing.
The honest test of healthy estimation is simple: does the team trust its own forecast, and does that forecast help them commit to a realistic Sprint Goal? If the points help the team plan and improve, they are working. If they have become a number people defend, perform to, or compare across teams, the technique has been hijacked — and no amount of finer estimation will fix a problem of trust.
If estimation in your teams has drifted into theatre and you want it back to a genuine planning tool, XNM's program & project delivery advisory can help your Scrum Teams estimate to inform rather than to perform.