In a recent thread on the Scrum Development mailing list, Paul Battison asked whether his team should re-estimate completed stories after the sprint is done, so as to have the team's velocity reflect the actual effort that went into completing the stories.
The rough consensus? Don't rework your estimates on completed stories.
On consideration, it's hard to find a lot of value in the practice of re-estimating stories once they are complete. Kelly Waters explains why:
The beauty of Velocity is that statistically it compensates for bad estimating. The consequences of unplanned tasks—e.g. a user story being estimated at 3 points and turning out more like a 13 in reality—is that the team still only scores 3 points for it. The consequence of this is that the team's Velocity is lower than expected, meaning that the team plans future Sprints based on a more realistic target, with the team's actual Velocity being based on what they had thought when the user stories were estimated.
Over the course of several sprints, a team's velocity will therefore naturally adjust to accomodate story estimates that are habitually too low or too high. The velocity will become more accurate on its own—no need for special post-facto adjustments to bring it into line.
Indeed, adjusting the estimates of completed stories is more likely to be harmful than merely useless. Paul Oldfield writes:
[...] if you adjust the backlog your existing velocity is thrown in doubt. How important is it that you need to predict well over the next few iterations? It may take that long to get back to a velocity that is reasonably reliable.
The point of making estimates of stories is to determine the team's velocity. What is velocity? According to the Scrum Alliance, "
In Scrum, velocity is how much product backlog effort a team can handle in one sprint." Tweaking estimates after-the-fact reduces the predictive ability of velocity for future sprints by mixing story estimations made before sprints with "estimations" of stories made after sprints are complete. Comparing and reasoning between these two types of estimates is very difficult to do—perhaps impossible.
Should you never re-estimate completed stories? Almost never, but there are exceptions. Mike Cohn writes:
Generally re-estimating is useful when you completely blew it on the original estimate and can see that the mistake was a rare occurrence. (That is, if every estimate is systematically off by half I wouldn't re-estimate.) Second, you should re-estimate when there has been a change in relative size. For example, the team has discovered that learning AJAX will be about half as hard as they thought. We'd want to fix that because the new knowledge tells us that our relative estimates are off-kilter for the AJAX-heavy stories.
In general, though, it's best not to change the estimates for your team's completed stories. There is a powerful impulse to fix those estimates based on what you know now, but in most cases, that impulse should be resisted.
