Re-estimating story points

Re-estimating completed work breaks velocity. Re-estimating carried-over work is the only honest case.

The question comes up every quarter or so. "We sized this as a 5, it was actually a 13 — should we update it?" The instinct that says yes is the same instinct that wants every number to be retroactively correct. It's wrong. Velocity is the rate at which the team — at the calibration they had at the time — completed work; it's a forecast input, not a historical record. Going back and rewriting the points the team voted with rewrites the calibration along with the points, and the forecast that used to work stops working.

There's one case where re-estimating is the right call, and it has nothing to do with "the estimate was wrong." It's stories that didn't finish in the sprint they were committed to and are now carrying over. The team learned something about that story in the sprint that just ended. The remaining work is a different thing from the original story — usually smaller, sometimes bigger, almost always more concrete. Re-estimate the remaining work for the new sprint. Don't re-estimate the original.

The cases people get wrong

"The team got faster, so old stories should be smaller." No — your team got faster, so the same work earns the team more points per sprint, which is what velocity is for. Touching the historical points removes the only signal that the team improved.

"This 5 turned out to be a 13. Let's update it." The wrong question. The right one: why was it sized as a 5? If a 5 hid scope a 13 would have surfaced, that's a refinement signal — see stories that can't be estimated for the splitting version of the same problem. Use the discovery to size the next story like it more accurately, not to rewrite this one's history.

"We changed our reference story; everything before it is now wrong." Yes, technically. The fix isn't to re-estimate every story you've ever shipped. The fix is to recognize velocity has been rebased and start the new average from this sprint. Three sprints later the new average is meaningful and the old one is gone, which is the same outcome you'd reach by carefully revising everything, with less effort and fewer arguments.

"A spike turned up information that makes the next story trivial." Now that's a real re-estimation — and it isn't the spike's points changing, it's the downstream story being a different size now that the unknown is gone. Re-estimate the downstream story, not the spike.

The one case where you should

Carry-over. The story didn't finish, the sprint is closing, the remaining work goes into next sprint's commitment. That remaining work is materially different from what was sized at the start — the team has done some of it, found at least one unknown, and has a clearer view of what's left. Vote it again as if it were a new story. Use the original estimate as a sanity check, not as a constraint.

Whatever the team produces under this rule, the original sprint counts the original points (toward the sprint's burndown narrative, not toward velocity, since the story didn't finish). The new sprint counts the new points when the carry-over completes. Velocity stays a forecast that survives the team learning things, which is the whole reason the technique works.

Re-estimate carry-over. Leave completed work alone. If you reach for the eraser, you're optimizing the wrong thing.

Adjacent: velocity for what re-estimating breaks; can't estimate this story for the refinement question hiding inside most "we mis-sized this" conversations.