Velocity: Measuring and Planning an Agile Project

December 10, 2007 by Jeremy Weiskotten

Bridgekeeper: “What is the velocity of an unladen swallow?”
King Arthur: “An African or European swallow?”
Bridgekeeper: “Huh? I don’t know that…”

- Monty Python and the Holy Grail

One of the most important metrics of an Agile team is its velocity. (No, you don't have to give the receptionist a stopwatch and do laps around your office.) In project management terms, velocity is the amount of work that a team can complete in a specified period of time.

The "amount of work" is the total number of story points if the team estimates by size, or the total number of "ideal hours” spent on tasks. All acceptance criteria must be met in order for a story to be considered “complete”. The "specified period of time" is usually an iteration between one and four weeks long.

Velocity is simply work divided by time — story points per iteration or ideal hours per iteration.

Velocity gives you an idea of how much work can realistically be completed in an iteration, and by estimating the size of your story backlog, you can determine with relative accuracy when you will meet your project’s milestones, including final release. Without determining the team’s velocity and estimating the backlog based on real experience, project and iteration planning is harder to do and less accurate.

It’s easy to get started.

If you’re just getting started with Agile, stories, story points, velocity, etc., you probably have no idea what your velocity is or should be. Every team is different, and every team estimates differently, so there’s no formula. However, once you’ve completed your first iteration you can compute the velocity for that iteration in just a couple of minutes to establish a baseline.

A team should recalculate its velocity at the end of each iteration and compare it with past results. Depending on the answer, you might have to face some interesting questions:

Is the team getting faster or slower? If so, why is the velocity changing, and should we expect the change to be temporary or permanent?

Velocity is naturally affected by resource fluctuations: team members get sick, take vacation, or get shipped off for training. If a productive team member retires or moves on to another opportunity, the team’s velocity will almost certainly suffer, and if you choose to fill that person’s seat, some team members might be called upon to review resumes and screen and interview candidates. New hires usually cause a temporary drain on resources – until they get up to speed your overall velocity may go down for an iteration or two because experienced team members will spend time teaching the new fish about the domain, development environment, team/company standards and values, and existing code.

A big increase in velocity can look good on paper, but it may not be a good sign. It might indicate that some estimates were too high (use revised estimates that are closer to the “actual” experienced) or just that your math was wrong (it happens). It might also indicate that at least some of the team is burning the midnight oil – maintaining a sustainable pace and encouraging a good work/life balance are important in avoiding burnout.

What was the margin of error of our estimates, and is it getting larger or smaller? A smaller margin of error indicates better estimates and a more accurate overall project plan. A larger margin of error reduces the certainty that you will hit milestones down the road on schedule. Don’t be afraid to revise estimates during an iteration as you learn more, and remember to keep estimates in the backlog current as well. Reflecting this new knowledge back to the project schedule allows you to raise concerns as early as possible.

Is our velocity good enough to satisfy business requirements? Deadlines are a reality in almost every environment. If we can’t sacrifice features, how can your team do more work in the same amount of time without sacrificing quality? Are we spending too much time on up-front design, in meetings that can be avoided, or waiting for dependencies to fall into place? Do we need to hire more people, or just an expert in a particular area?

Conclusion

Knowing and understanding your team's velocity allows you to make commitments with confidence. It's easy to calculate, so do it often and track the performance of your team over time as a sanity check with your schedule.

Permalink