“There’s no sense in being precise when you don’t even know what you’re talking about.”
—John von Neumann
One of the most common questions about estimating with story points or ideal days is “When do we re-estimate?” To arrive at an answer it is critical to remember that story points and ideal days are estimates of the overall size and complexity of the feature being implemented. Story points in particular are not an estimate of the amount of time it takes to implement a feature, even though we often fall into the trap of thinking of them as such. The amount of time that implementing a feature will take is a function of its size (estimated in either ideal days or story points) and the team’s rate of progress (as reflected by its velocity).
If we keep in mind that story points and ideal time estimate size, it’s easier to see that we should re-estimate only when we believe a story’s relative size has changed. When working with story points or ideal time, we do not re-estimate solely because a story took longer to implement than we thought. The best way to see this is through some examples.
Throughout the rest of this chapter and some of the upcoming chapters, we will be working on SwimStats, a hypothetical website for swimmers and swim coaches. SwimStats will be sold as a service to competitive age-group, school, and college swim teams. Coaches will use it to keep track of their roster of swimmers, organize workouts, and prepare for meets; swimmers will use the site to see meet results, check their personal records, and track improvements over time. Officials at swim meets will enter results into the system. A sample screen from SwimStats is shown in Figure 7.1.
Using SwimStats as an example, let’s first look briefly at a case when we should not re-estimate. Suppose we have the stories shown in Table 7.1. At the conclusion of the first iteration, the first two stories are complete. The team doesn’t feel good about this because they thought they would complete twice as many points (twelve rather than six) per iteration. They decide that each of those stories was twice as big or complex as initially thought, which is why they took twice as long as expected to complete. The team decides to double the number of story points associated with each. This means that their velocity was twelve (two six-point stories), which they feel better about.
However, before the project started, the team considered all four stories of Table 7.1 to be of equivalent size and complexity, so each was estimated at three story points. Because they still believe these stories are equivalent, the estimates for Stories 3 and 4 must now also be doubled. The team has given themselves more points for the stories they completed, which doubled their velocity. But, because they also doubled the amount of work remaining in the project, their situation is the same as if they’d left all the estimates at three and velocity at six.
What’s happened here is that velocity is the great equalizer. Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. We cannot simply roll a die and assign that number as the estimate to a feature. However, as long as we are consistent with our estimates, measuring velocity over the first few iterations will allow us to hone in on a reliable schedule.
Let’s look at another example. Suppose a project consists of fifty user stories, each of which is estimated as one story point. For simplicity, suppose that I am the only person working on this project and that I expect I can complete one story point per work day. So on a two-week iteration, I expect to finish ten stories and have a velocity of ten. Further, I expect to finish the project in five iterations (ten weeks). However, after the first iteration, rather than having completed ten stories, I’ve completed only five. If I let velocity take care of correcting my misperceptions, I will realize that the project will take ten iterations, because my velocity is half of what I’d planned.
What happens, though, if I re-estimate? Suppose I re-estimate the five completed stories, assigning each an estimate of two. My velocity is now ten (five completed stories, each re-estimated at two), and forty-five points of work remain. With a velocity of ten and with forty-five points remaining, I expect to finish the project in 4.5 iterations. The problem with this is that I am mixing revised and original estimates. Using hindsight, I have re-estimated the completed stories at two points each. Unfortunately, when still looking forward at the remaining forty-five stories, I cannot predict which of those one-point stories I will want to say were worth two points in hindsight.
Let’s continue working on the SwimStats website, this time with the user stories and estimates shown in Table 7.2.
The first three of these stories each has to do with displaying a chart for the user. Suppose the team has planned the first iteration to include Stories 1, 2, and 6 from Table 7.2. Their planned velocity is thirteen. However, at the end of the iteration they have finished only Stories 1 and 6. They say they got less done than expected because Story 1 was much harder than expected and that it should have been “at least a six.” Suppose that rather than one difficult story, the team has completely underestimated the general difficulty of displaying charts. In that case, if Story 1 turned out to be twice as big as expected, we can expect the same of Stories 2 and 3.
Let’s see how this plays out across three scenarios.
In this scenario, we will leave all estimates alone. The team achieved a velocity of eight points in the last iteration. That leads us to the expectation that they’ll average eight points in the upcoming iterations. However, the team knows they cannot complete Stories 2 and 3 in a single iteration, even though they represent only eight points. Because each of those stories involves charting, and because the team expects each charting story to be twice as big as its current estimate (just like Story 1 was), the team concludes that they cannot do Stories 2 and 3 in one iteration. It’s eight points, but it’s too much.
In this scenario, let’s see if adjusting only the estimate of Story 1 fixes this problem. After finishing the iteration, the team felt that Story 1 was twice as big as had been expected. So they decide to re-estimate it at six instead of three. That means that velocity for the prior iteration was eleven—six points for Story 1 and five points for Story 6.
Because no other stories are re-estimated, the team plans its next iteration to comprise Stories 2, 3, and 4. These stories are worth eleven points, the same amount of work completed in the prior iteration. However, they run into the same problem as in the first scenario: Stories 2 and 3 will probably take twice as long as expected, and the team will not be able to average eleven points per iteration, as expected.
In this scenario, the team re-estimates each of the charting stories. The estimates for Stories 1, 2, and 3 are double what is shown in Table 7.2. As in the second scenario, velocity for the first iteration is eleven—six points for Story 1 and five points for Story 6. Because velocity was eleven in the first iteration, the team expects approximately that velocity in the next iteration. However, when they plan their next iteration, only Story 2 will be selected. This story, initially estimated as five, was doubled to ten and is so big there is no room for an additional story.
Re-estimating was helpful only in this third scenario. This means that you should re-estimate a story only when its relative size has changed.
You may also wish to re-estimate when the team finishes only a portion of a story during an iteration. Suppose the team has been working on a story that says, “As a coach, I can have the system recommend who should swim in each event.” This story is initially estimated as five points, but it is deceptively complex.
Teams in a swim meet receive points based on the finishing places of the swimmers. However, planning for a swim meet is not as easy as putting the team’s fastest swimmer for each event into that event. Each swimmer is limited in the number of events he or she can swim. This means we may not elect to have Savannah swim the 100-meter backstroke because we need her more in the 100-meter breaststroke. So suppose the team reaches the end of the iteration, and the system can optimize the assignment of swimmers to individual events. However, the team has not begun to think about how to assign swimmers to relay events. How many points should the team count toward the velocity of the current iteration? How many points should they assign to the remaining work?
First, let me point out that I’m generally in favor of an all-or-nothing stance toward counting velocity: if a story is done (coded, tested, and accepted by the product owner), the team earns all the points, but if anything on the story isn’t done, they earn nothing. At the end of an iteration, this is the easiest case to assess: If everything is done, they get all the points; if anything is missing, they get no points. If the team is likely to take on the remaining portion of the story in the next iteration, this works well. Their velocity in the first iteration is a bit lower than expected because they got no credit for partially completing a story. In the second iteration, however, their velocity will be higher than expected because they’ll get all of the points, even though some work had been completed prior to the start of the iteration. This works well as long as everyone remembers that we’re mostly interested in the team’s average velocity over time, not in whether velocity jumped up or down in a given iteration.
However, in some cases the unfinished portion of a story may not be done in the next iteration. In these cases it can be appropriate to allow the team to take partial credit for the completed portion of the story. The remaining story (which is a subset of the initial story) is re-estimated based on the team’s current knowledge. In this case, the original story was estimated at five points. If the team feels that the subset they completed (scheduling individual events) is equivalent to three points or ideal days, they will give themselves that much credit. The unfinished portion of the original story in this case could be rewritten to be “As a coach, I can have the system recommend who should swim in each relay.” The team could then estimate that smaller story relative to all other stories. The combined estimates would not need to equal the original estimate of five.
Do not become overly concerned with the need to re-estimate. Whenever the team feels one or more stories are misestimated relative to other stories, re-estimate as few stories as possible to bring the relative estimates back in line. Use re-estimating as a learning experience for estimating future user stories. As Tom Poppendieck has taught me, “Failure to learn is the only true failure.” Learn from each re-estimated story, and turn the experience into a success.
Remembering that story points and ideal days are estimates of the size of a feature helps you know when to re-estimate. You should re-estimate only when your opinion of the relative size of one or more stories has changed. Do not re-estimate solely because progress is not coming as rapidly as you’d expected. Let velocity, the great equalizer, take care of most estimation inaccuracies.
At the end of an iteration, I do not recommend giving partial credit for partially finished user stories. My preference is for a team to count the entire estimate toward their velocity (if they completely finished and the feature has been accepted by the product owner) or for them to count nothing toward their story otherwise. However, the team may choose to re-estimate partially complete user stories. Typically, this will mean estimating a user story representing the work that was completed during the iteration and one or more user stories that describe the remaining work. The sum of these estimates does not need to equal the initial estimate.