Velocity: How Much Did We Get Done?

This is the trickiest part of the simulation: explaining the concept of velocity after the first iteration.

After each iteration, each team announces the number of business points earned and the sum of the estimated durations of the implemented stories. These numbers are easily found on the planning sheets. Let's call the sum of the estimated durations X. Note that we don't know the actual duration of each story, because we use an hourglass.

What we want to know is, how many stories can we implement in one (180-second) iteration? Well, we just did such an iteration. How many stories did we implement? We implemented some stories requiring X amount of work. How much work will we be able to perform next time? The Yesterday's Weather rule says, probably about the same amount as in the previous iteration. That's if we don't take sick leave, holidays, interruptions, team learning, reuse, refactoring, and a thousand other details into account.

Let's give X a name: "Velocity." Velocity measures how much work the team can do per iteration. If we want to finish the next iteration on time, each team will schedule its Velocity's worth of stories.

If Velocity is effort per iteration, the story estimates don't represent time, but estimated effort. We no longer estimate in seconds, but in "points" or whatever you like as a unit of programming effort. How can we estimate using this made-up unit system? We estimate by comparing with other stories: If a new story is about as difficult as an implemented story, give it the same number of points. If it looks twice as difficult, give it twice the points. These points really express the relative complexity of the stories. Maybe a good name would be "complexity points." The important thing is to estimate consistently.

What about all these pesky factors that influence how much work the team can do? We let the velocity take care of them. If the team learns about the domain or reuses more code, they get more done. Their measured velocity rises; they take on more work. If new members join the team or people go on holiday, the measured velocity decreases, and the team takes on less work. It really is that simple! The most difficult thing is not to take all those factors into account when estimating.

Does this really work? In the simulation, the teams typically underestimate the stories in the first iteration and end with a velocity lower than 180, which indicates that few teams can estimate even these simple stories accurately. In the second iteration, they get to ask for more stories (because they get better at doing the implementations) and increase their velocity. By the third iteration, they get pretty close. In real life, the authors have experienced that the velocity stabilizes after only a few iterations. This has been observed in teams that worked for several iterations on the same project and in teams working on different projects in the same domain, using the same tools. Expect your velocity to change dramatically if you change your team, problem domain, tools, or environment.