Velocity: “the speed of something in a given direction.” And how do you measure it while driving? How do you know that your average velocity is 80 km per hour if you have traveled 160 kilometers in 2 hours’ time? I.e. kilometers traveled in one hour. The same goes for an agile project. Agile Velocity is an extremely simple, powerful method for accurately measuring the rate at which scrum development teams consistently deliver business value. This article explains the principles behind agile velocity tracking.
Note: The main idea behind agile velocity is to provide a lightweight methodology for measuring the pace at which a team is working and to assist in estimating the time needed to produce additional value in a software-development project.
Agile velocity is the rate at which a team delivers stories from the product backlog. To calculate velocity of your agile team, simply add up the estimates of the features, user stories, requirements or backlog items successfully delivered in an iteration, I.e. the sum of the estimates of delivered (i.e., accepted) features per iteration. Agile velocity is measured in the same units as feature estimates, whether this is story points, days, ideal days, or hours that the Scrum team delivers – all of which are considered acceptable. Agile delivery cycles are very small so velocity quickly emerges and can be validated very early in a project and then relied upon to improve project predictability.
- Version One “An extremely simple, powerful method for accurately measuring the rate at which Scrum development teams consistently deliver business value, with story points, days, and hours all being acceptable units of measurement.”
- Scrum Alliance “How much product backlog effort a team can handle in one sprint”
- Agile Alliance “The sum of effort estimates associated with user stories that were completed during an iteration.”
All of these definitions have the same intent, which is to establish and measure a “constant pace” that can be maintained indefinitely, as described in the Agile Manifesto. A team delivers 20 and 30 story points in the first & second iteration respectively. The average velocity = Sum of Story points delivered / Number of iterations = (20 + 30)/2 = 25 Story points!
Velocity Calculation Guidelines
There are some simple guidelines for estimating initial velocity of your Scrum team prior to completing the first iteration, but after that point you should use proven, historical measures for planning features. A general guideline is to plan initial velocity at one-third of available time. As an example, with six programmers and two-week iterations, a total of 60 programmer-days (6 programmers x 10 days) are available. In this situation, a good start would be to plan 20 ideal days’ worth of work in the iteration. If using actual time, include enough of a buffer to account for standard project overhead and estimation inaccuracy. As fast as the next iteration, velocity can be measured and adjusted. For the second iteration the Scrum team should then use the first iteration as a guideline. Typically agile velocity will stabilize through the life of a project unless the project team make-up varies widely or the length of the iteration changes. Velocity tremendously simplifies and accelerates the whole project planning, estimation, status tracking, and reporting process.
Note: Generally meetings, phone calls, emails, etc. are NOT included in agile velocity calculation since goal of velocity is relative consistency and predictability across iterations in terms of an agile team’s ability to deliver.
- If velocity fluctuates widely for more than one or two iterations, the Scrum team may need to re-estimate and/or renegotiate the release plan.
- 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.
- Only the aggregate velocity of the team matters, and the phrase “individual velocity” is meaningless
- Once you get past the first month or two of a project, the velocity should settle into a tight, consistent range. Volatility is the measure of consistency (or lack thereof) in velocity over time. The higher the volatility, the riskier the predictions made based on that team’s velocity.
- Instead of a speedometer, agile velocity is more like a measurement of a team’s rhythm and should be used to monitor team health.
Maximum velocity is NOT EQUAL to Maximum productivity
In an attempt to maximize velocity, a team may in fact achieve the opposite. If asked to maximize velocity, a team may skimp on unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize refactoring, or many other key benefits of the various agile development practices. While potentially offering short-term improvement, there will be a negative long-term impact. The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
Why do we need Agile Velocity?
If you know the velocity, you’ll have an idea about:
- Reporting: How much value you’ve delivered until now (in story points or user stories)
- Planning: When you’ll be able to deliver all user stories in the product backlog
- How much scope (user stories or story points) can be delivered by a specific date
- Limit on the amount of work to be taken on in further iterations.
- The functional health of the team and the processes it follows
- Identifying and removing obstacles that affect velocity
- Identifying training needs
- Adjusting project scope and business priorities, and forecasting major release dates
- Resource and project planning
Note: Just like driving a car, agile velocity too might get impacted due to roadblocks (blockers), fuel (motivation), driver (team knowledge & experience), car conditions (environment), visibility (Project Transparency), directions (Project objectives), and traffic (processes).
Agile Velocity | It’s simple, really
Yes, it is. Do not try to over-complicate velocity – it really is a straight forward concept and a great deal of its value lies in its inherent simplicity. It is easy to measure and track a team’s velocity over time. Many managers and teams new to agile methods tend to over-analyze the concept of agile velocity and heap too much complexity around it.
Originally, advocates of Extreme Programming estimated in terms of Load Factor, which was the inverse of velocity, being time/work. “We think velocity is the simpler term, so Load Factor is falling out of use,” Robert C. Martin wrote in 2000. Kent Beck said much the same in his 2000 book, Planning Extreme Programming: “We used to use load factor a lot in planning, but since then we have learned that it’s easier to just use velocity.”
It’s important to monitor how agile velocity evolves over time. Like burndown charts, velocity charts are invaluable as they provide insight into how a team is progressing with their current and any previous iterations. New teams can expect to see an increase in velocity as the team optimizes relationships and the work process. Existing teams can track their velocity to ensure consistent performance over time, and can confirm that a particular process change made improvements or not. Beyond a basic understanding, it’s important that you learn how to measure, influence and improve upon it. Agile Velocity is a useful planning tool for estimating how fast work can be completed and how long it will take to complete a project.
So, what’s holding you back from measuring your team’s velocity?