Understand Velocity

First, understand the definition of velocity in agile approaches. Velocity is a rate of change coupled with a direction. Velocity is not acceleration.

Imagine you’re driving to an appointment 10 miles away. You drive the posted speed on the side streets, one velocity. As you enter a highway, you accelerate to achieve highway speed. As you continue to drive, you achieve a stable state: You get into a lane and maintain a constant speed, with any luck. You stay stable with respect to the road and your direction. Your velocity stays the same—especially if you use your cruise control. The more steady the traffic and the more you use your cruise control, the more your velocity stays the same. You arrive at your destination at the time you expect to.

Now imagine these scenarios: the highway is gridlocked. You are not going to achieve your expected highway velocity. You will be late. Or imagine that it has just snowed three feet and it takes you more than twice the time you estimated just to get to the highway. You will not make your appointment on time.

That’s the problem with using velocity as a way to estimate. A team’s velocity depends on achieving a stable rate of completion, which often depends on a stable relative size of story and the context in which the team works on that story. If the team is trying to estimate something inside crufty code, even if the story is straightforward, the work will take the team longer. The team will have to create enough tests and possibly try some experiments before it can say it has solved the problem.

You can use velocity as a basis for estimation. Some teams are successful using velocity as a way to estimate, once they have achieved a stable rate of completion. That stable rate often takes six or seven iterations to achieve.

Think of velocity as capacity. Your team can, on average, deliver some number of stories, some number of fixes, maybe something else. Velocity is not acceleration.