Agile & Lean Metrics: Velocity

Great teams constantly improve the way they work in order to deliver high quality software. This series of blog posts will help you do just that. We'll introduce a set of key performance indicators that you can use as a baseline for your continuous improvement efforts. We think that a good indicator is easy to understand, and it should be leading rather than lagging i.e it should predict successful software development.

In the previous post I explained how understanding your cycle time helps you to become more agile, and better at predicting your delivery dates. In this post I want to introduce another, related, metric that is essential when predicting how much work can be completed in a given time period: velocity. 

Velocity is a unit-less metrics used in agile methodologies like XP and Scrum. It's a measure that tells the team how much work they should take for an iteration based on how much they have completed in the past iterations. For example, if the team completed 10 units of work on the first iteration and 15 units on the second iteration, then the team's average velocity is 12,5 units per iteration. That number should be used as a guideline when choosing how many units of work to include in the third iteration. 
 

Why you should care about velocity?

When velocity remains somewhat stable, it can be used for estimating how long it will take to complete the remaining scope of work. If there's 50 units of work left, a team averaging 12,5 units per iteration is likely to complete all the work in four iterations. If each iteration takes two weeks, it will take a total of 8 weeks of calendar time. 

It is important to understand that the velocity is not a performance metric but rather a forecasting tool. The primary use for velocity is to help figuring out how much work can be completed in a given time period based on how quickly similar work was previously completed. As such, the absolute number is not of importance but rather how much it varies from one iteration to another. Less volatility leads to more reliable forecasts. Therefore, a team should strive to find the pace of work that they can keep from iteration to iteration without having to constantly stretch, or to work overtime. 
 

Visualising velocity

Velocity is usually reported per iteration, which shows its development from one iteration to another, but also provides insight to the volatility: If there's high variation between iterations, it reveals that the team hasn't yet found it's constant pace of work. It could be due to changes in the team composition. Since velocity is always specific to a team, any changes in the team structure requires recalculation. 

Velocity tends to get more stable once the team works together over a longer period of time and gets more routine.

The chart above shows how much work was completed in an iteration. But did the team complete all the work that they thought they could? An alternative representation, consisting of two bars per iteration, provides additional insight into how well the team has been able to predict the amount of work they can commit to complete in an iteration: 

What if there were changes to the scope during the iteration? Some new unplanned work was uncovered that was so urgent that it couldn't wait until the next iteration. That happens. Such scope changes can visualised by introducing another colour, yellow in this case, to denote the added scope:

As can be seen, visualising velocity using techniques like above can help you to make informed judgements when it comes to planning your iterations. Looking at the differences between committed and completed bars, or the ratio of added work, can help you spot unwanted behaviour that might have a negative affect on team morale if not addressed. 

However, the main goal should never be in perfecting the process, but rather finding the best ways to reach your goals. Every team is unique so pick the methods that work for you!
 

How to track velocity?

In order to track your team's velocity, you need to record the amount of work completed in each iteration. For teams using the Scrum methodology, the obvious time to do that is during the sprint review session. The Scrum master takes the completed stories and calculates the total number of story points completed in the sprint. If you don't have the habit of estimating stories, you simply count the number of stories completed. When using an electronic tool, the the total number of points is typically reported when the sprint is marked as complete. 

What to do with partially completed stories? My advice would be to exclude them completely. Why you should not count for the work already completed? Well, the first reason is that you never truly know how far you are and how much work is left. We're all familiar with that 90% ready feeling - almost there! - until we later find out that the remaining 10% took most of time. 

Another reason is that partially completed stories, when repeatedly encountered, are often a symptom of bad planning and inadequate story splitting. By not counting the unfinished work, you encourage team to slice their stories into smaller bits of work they can complete during an iteration. That's always a good thing to do!