| Some ideas about updating estimates, mid-iteration estimate changes, and 0-point stories. |
Updating Estimates
Suppose your velocity is 2. Your customer has selected one 2-point story, and in the exact middle of the iteration you find you’re done with that story.
Should you:
A. Revise the estimate to a 1? (Since you took half the week in a 2-point week.)
B. Keep the estimate a 2 and take the boost in velocity?
If you think of your estimates as “one point = half a week”, you’ll take the ‘A’ approach. If you say, “It’s a 2 because it looks about as hard as the other 2’s” then you’ll take the ‘B’ approach.
Bottom Line: Alternative A will drive you crazy. Make story estimates relative to each other, not the calendar.
If you take alternative A to its logical extreme, your velocity will be essentially constant:
Iteration 1: You finish a 3-point story.
Iteration 2: Schedule 3 points. Finish one 3-point story mid-iteration, and another during the rest of the iteration. So you downgrade all 3-point stories to 1.5 points.
Iteration 3: Schedule 3 points. You complete 3 of the 1.5-point stories and decide they should all be 1-pointers. New velocity: 3 points/iteration.
In real life, there’s probably enough noise to make it non-obvious that your velocity is “constant.”
For alternative B, we keep the stories as originally estimated:
Iteration 1: Estimate 3, actual 3.
Iteration 2: Estimate 3, actual 6.
Iteration 3: Estimate 6, actual 9.
This is a better reflection of what’s happening. Just like you can’t stand in the same river twice, you don’t have the same team you started with (they’ve learned). The growing velocity reflects their learning.
Should you ever revise an estimate post facto? Yes, if you realize that you didn’t have all the information you needed. If you estimated it a 2 because you expected certain tasks, and half of them turned out to be not needed after all, you might revise the estimate down. The question is, “Knowing what I know now about what was involved for this story, was it about as hard as these others?”
Relative estimates compare stories on their own terms. Adjusting estimates to reflect velocity confuses that.
Mid-Iteration Revisions
Suppose a story turns out to be significantly harder than expected, but the team gets it done anyway. Or a story is introduced partway through an iteration (ugh!), needing an estimate and implementation.
What is the team going to do?
If they score it high, they raise the amount of work planned in the next iteration. (In this iteration, the work is already a sunk cost.) So the team’s incentive is to score it low.
Mis-scoring a story will distort the velocity.
Most teams want to do the right thing, but having incentives mis-aligned makes it harder. Try to avoid this.
Zero-Point Stories
Some stories are truly trivial. (For example, you have a field set to “10-point Times” and you need “12-point Courier.”) These are the kind of thing that take a few minutes, and are no additional work if you’re in that part of the code anyway. The team will be tempted to score them as “0 points,” and they sort of are.
But if you spent a whole iteration doing zero-point stories, your velocity would be 0. Each story is small but valuable, but they do take some time. And how cheap are they really? You have to revise an acceptance test, a unit test, and the code. You may have extra refactoring to do: now you know that this is a flex point; have you missed some duplication? Should the customer be thinking about a preferences facility?
Some teams don’t allow zero-point stories. Other teams allow them but add them to a non-zero-point story (so there are no stand-alone zero-point stories). Some teams allow them, but insist that they’re prioritized among the other stories. Some teams just allow them and don’t worry about it.
I favor combining them with another story if it makes sense. If not, I’d like them put on a card and prioritized.
Conclusion
These musings have the same theme: there are subtle ways to distort your velocity:
- Updating estimates by the calendar (rather than by the work) will confuse you.
- New stories in mid-iteration tempt a team to distort next iteration’s velocity.
- Zero-point stories make it seem like you’re getting less done than you are, and tempt you to fix only the surface problem.
Resources and Related Articles
- “Story Time: Release Planning” (chapter 7 of Extreme Programming Explored, by Bill Wake.) Discussion of planning as a game, and more on the customer’s role.
- Planning Extreme Programming by Kent Beck and Martin Fowler.
[Written June, 2002.]