BT

Re-estimate Completed User Stories for a More Accurate Velocity?

by Dan Puckett on Sep 02, 2010 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Estimating old stories by Raghuveer Rao

Postmortems are good if the scrum is ready to learn from their mistakes. There is no point in resizing unless we figure out why the story was undersized in the first place. If the resizing exercise helps the team in avoiding mistakes in the future the scrum should do it.

If the scrum is resizing every iteration then there is something wrong with the process.

Re: Estimating old stories by Morgan Creighton

Raghuveer makes a good insight, that resizing as a postmortem activity can help the team estimate better in the future. I love that idea. For many teams, that exercise seems worth doing.

But, for the many reasons mentioned in the article, going back and adjusting the velocity based on those new numbers does not feel justified. It would be a bit of a cheat.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT