Velocity: Measuring and Planning an Agile Project


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.

4 thoughts on “Velocity: Measuring and Planning an Agile Project”

  1. In order to get the most accurate velocity measurement, should a scrum master or team leader keep track of all hours NOT spent on a story? For example: sick time, vacation time, time spent helping other teams, time spent at HR meetings, time spent on tasks that were judged important but which did not map back to the stories for the iteration…..

    If we should keep track of this “non-story” time, in how much detail?

    Or do we just assume that after a few iterations, all this stuff averages out for the whole team, with different distractions hitting different individuals in such a way that it will al level out?

  2. Jim, in Scrum velocity is just a number of story points (or ideal days) per sprint. It has little to do with the real time and amount of hours spent on meetings and sick lives. Naturally these things are related and the team might like examining them if their velocity is very unstable, however, velocity itself is a Product Owner facing artifact.

    Product Owner needs to know the team velocity in order to make the release related decisions. For example, if there are 100 story points of work in the product backlog and the team velocity is usually around 15-20, PO can expect that 5-7 sprints are needed in order to complete his requests and can make the business decisions based on that information. For instance, if the mobile phone industry trade show is 3 sprints ahead, he can reprioritize the stories so that iPhone facing features were developed first instead of last as was originally planned.

Leave a Reply

Your email address will not be published. Required fields are marked *