One of the most important things for any agile team to understand is their velocity. Velocity is a term used in agile software development to illustrate the “rate of progress” for a team, related to a project or program.
What is it?
The simplest way to define velocity is “the number of user stories a team can deliver in one iteration” (meaning something that is done and potentially ready to ship). In short, velocity is how fast you are developing your software.
Velocity is a powerful method for accurately measuring the rate at which teams consistently deliver business value. To calculate velocity, simply add up the estimates of the user stories (features, requirements, etc.) successfully delivered in an iteration.
There are some simple guidelines for estimating initial velocity prior to completing the first iteration, but after that teams should use proven, historical measures for planning features. Within a short time, velocity typically stabilises and provides a tremendous basis for improving the accuracy and reliability of both near-term and longer-term project planning.
Agile delivery cycles are very small (I always suggest one week) so velocity emerges very early in a project and can be used to improve predictability.
Try not to overcomplicate velocity as a great deal of its value lies in its inherent simplicity. Many managers and teams new to agile methods tend to over-analyse the concept of velocity and heap too much complexity around it. After a few months of project experience, most people will experience an “ah-ha” moment with velocity, shedding any baggage they’ve associated with it and appreciating its simplicity and intrinsic value.
Why track it?
If a team does not know its velocity, how will that team ever be able to know how much work to put into iteration? If a team doesn’t focus on determining its velocity, it is almost a 100% probability that the team will miss the scope of most iterations – usually by a lot! If that happens, what good has it been to adopt an agile development process? Agile methods are used because they deliver predictable and repeatable results, but that only occurs if velocity is known.
Can velocity change over time?
Of course it can, and we hope it always increases, but we can’t PLAN on it increasing, we have to SEE it increase, understand why, then adapt. We need to make our future plans based on what we know. Many people call this technique using “yesterday’s weather” to predict the future.
When a team can confidently say “We can get X units of work done in each iteration” and really mean it, the project manager, stakeholders, customers and everyone else involved with the product can suddenly have confidence that things will be successful. The team has made a commitment and they will be sticking to it – sweet! Now everyone outside of the development team can do their jobs with some sense of knowledge about what and how much will be delivered over time. Of course there will be changes, but at least everyone has a frame of reference to go from.
One reason to adopt an agile process is to reduce risk. A major element of reducing risk can be accomplished by knowing the development velocity. Once that is known (and it may take a few iterations to get it honed), the risk of over commitment is vastly reduced. No one likes to over-promise and under-deliver, but that is what will happen on a regular basis if a team doesn’t know their velocity and modify things based on yesterday’s weather.
Frequently Asked Questions
How is velocity calculated?
Velocity is the sum of the estimates of delivered (e.g. accepted) stories per iteration.
What unit is used to measure velocity?
Velocity is measured in the same units as feature estimates, whether this is story-points, ideal days, or ideal hours – all of which are considered acceptable. I generally prefer story-points as these are a more abstract unit, and therefore less likely to be confused with actual or calendar time.
How is the first iteration’s velocity estimated?
A general guideline is to plan initial velocity at one-third of available time if estimating in ideal time in order to account for meetings, email, design, documentation, rework, collaboration, research, etc. As an example, with 4 engineers and 1-week iterations, a total of 160 ideal hours (4 engineers x 5 days x 8 hours) are available. In this situation, a good start would be to plan 53 ideal hours worth of work in the iteration. Remember that velocity will quickly emerge during the first iteration. If underestimated, velocity in the first iteration will rise, as new features are included; and if overestimated, velocity will decrease as features are removed. The second iteration should then use the first iteration as a guideline; the third iteration uses the second, etc.
Do meetings, phone calls, email, training get included in velocity?
They are typically not included – a goal of velocity is relative consistency and predictability across iterations in terms of a team’s ability to deliver value. As such, various activities that are not directly part of the development effort should not be accounted for. The only true measurement of velocity is the delivery of completed stories.
Should velocity be accumulated across teams or projects?
Velocity is very much a localised measure. In addition to different team members with different team personalities, projects typically possess unique characteristics in terms of estimating techniques, detail process, technology, customer involvement, etc. As a result, this can make organisation-wide analysis very inaccurate.
What if velocity fluctuates?
Velocity will typically fluctuate within a reasonable range, which is perfectly fine. If velocity fluctuates widely for more than one or two iterations, the team may need to re-estimate and/or renegotiate the release plan.
How long does it take for velocity to stabilise?
Team velocity will typically stabilise between 3 and 6 iterations – given the same team members and proportionate effort.
How do I to estimate future iterations?
Future iterations use the proven history of the team to determine how much the team can do. Therefore, velocity is the right measure to use for planning future iterations.
How do I estimate velocity if project teams change size?
Velocity relies on team consistency in order to be most valuable. If a team changes, use common sense in planning future iterations. If 20% of your team is unavailable for a couple iterations, then reduce planned velocity by 20% or so. If this includes a couple of key players, in particular a customer that may be less available, then reduce the estimate a little more. It will only take the length of the next iteration to understand better what the team can deliver and thus their new velocity.
Does maximum velocity mean maximum productivity?
Absolutely not. In an attempt to maximise velocity, a team may in fact achieve the opposite. If asked to maximise velocity, a team may skimp on unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimise re-factoring, or many other key benefits of the various agile development practices. While potentially offering short-term improvement (if you can call it that), there will be a negative long-term impact.The goal is not maximised velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
How do we measure velocity if our iteration lengths change?
You don’t, at least not nearly as easily. Velocity’s value comes from its inherent consistency. A fixed iteration length helps drive the reliable rhythm of a project. Without this rhythm, you are constant revising, re-estimating, and reconciling, and the ability to predict out in the future is minimised due to inconsistent results. If, on the other hand, almost everyone is going to be out a week for the holidays or a couple days for company-wide meetings, then by all means simply use common sense and adapt iteration dates or velocity accordingly. Like most agile practices, these are guidelines, not rules that are meant to prevent common sense.
If you need more detailed information about agile estimation, planning, Velocity and all similar topics I suggest reading Mike Cohn’s Agile Estimating and Planning. It is a very well-written and very accessible book.
