When Story Points Become a Performance: A Team's Quiet Reset
A product team — call them the Atlas squad — spent forty-five minutes most sprints arguing about whether a task was a 3 or a 5. They had a deck of planning poker cards, a velocity chart, and a Scrum Master who dutifully recorded every number. What they did not have was any benefit from the exercise. Forecasts were no better than guesses, and developers had quietly come to see estimation as a tax they paid to start the real work. By early 2022, with return-to-office disruptions thinning attendance, the ritual felt especially hollow. This is how they reset it.
First, it helps to be precise about what story points are for. Nothing in the Scrum Guide requires story points at all — the Guide says only that Product Backlog items are estimated by the Developers. Story points are a popular technique, not a rule. Their entire value is to support forecasting and a sustainable plan for the Sprint, not to measure people or to produce a number for a status report.
The theatre, named
When the Atlas squad listed what was actually happening, the dysfunctions were easy to spot — and most teams will recognize at least one.
Long debates over one point of difference, as if a 3 versus a 5 changed the plan.
Points treated as hours in disguise, so estimates carried false precision.
Velocity quoted to management as productivity, which pressured the team to inflate.
Re-estimating finished work to "make the numbers look right," which corrupted the only data they had.
The common thread: estimation had drifted from a conversation that builds shared understanding into a number-production line. The cards were still on the table, but the point of the exercise had left the room.
The reset that worked
The team did not abandon estimation. They stripped it back to what actually helps the Developers plan the Sprint and the Product Owner forecast roughly.
Estimate to surface disagreement, then stop. If two people picked 3 and 8, that gap meant they understood the work differently. They talked until the difference was clear, then took any reasonable number. The conversation was the deliverable, not the digit.
Time-box estimation hard. A couple of minutes per item. If it took longer, the item was too vague and went back for refinement rather than more debate.
Forecast with throughput, not just points. They started simply counting how many items they finished per Sprint. For many backlogs, item count forecasts as well as point totals and invites none of the gaming.
Banish velocity from status reports. Velocity stayed an internal planning aid. Stakeholders got a forecast of when work would likely be done, which is the question they were actually asking.
Within a few Sprints, planning was shorter and calmer, and the forecasts were no worse — in fact slightly better, because the team stopped gaming numbers they no longer felt judged on. The cards came out only when an estimate genuinely split the room. The rest of the time, a quick "small, medium, or needs refinement" did the job.
The lesson is not that story points are bad. It is that any estimation practice should be judged by one question: is it producing better shared understanding and good-enough forecasts? If you are spending real time generating numbers nobody uses to make a decision, you are doing theatre. Keep the part that helps you plan, and cut the rest without ceremony.
If your estimation and planning have turned into ritual without payoff, XNM's program & project delivery advisory can help your teams forecast honestly and plan with less friction.