Velocity as a tool not a weapon

In Agile development we build a backlog of future work.  We actively manage this through “backlog refinement”. With the backlog in place, we do our planning using timeboxes. A “timebox” is a fixed time period which here represents the time we have available to the delivery date. 

There is a challenge here to assess how backlog maps to timeboxes. Backlog is continuous and ordered. Timeboxes are discrete with fixed edges. How can we assess how deep in that backlog we might deliver within the timebox?  We can’t use a reductionist approach of detailed breakdown of all the work to the delivery point. We are unlikely to be able to use a “noestimates” approach unless the timeline is very short.

The best predictor of how long it will take to complete future work is past performance.  If it took us four weeks to complete work of a particular size last time, we can expect that to complete a similar amount will take another four weeks.

The best predictor of how long it will take to complete future work is past performance

We have the tools to manage that prediction.  We plan using relative estimation. 

An item with double the value has twice the complexity.  We can expect that it will take about twice as long.  Estimation however is not enough. We would like to start to build an idea of a timeline.  How do we map those sizing scores to time?

About velocity

Our key tool for mapping estimates to time is called Velocity.  Velocity is the amount of estimated work we complete divided by the elapsed time to complete that work.  We can measure the speed at which the team achieve work and we can use that to predict the likely amount of work they will achieve in the future. 

So for example a velocity of 5 per day means that on average every calendar day the team complete work with a total score of 5.  If working in iterations you will also see velocity quoted in score per iteration.  Personally I prefer the score per day measure.  Just be clear which you are using.

Remember that velocity works whatever approach to estimation is being taken.  If we use the rightsizing approach, then “5” will mean “5 product backlog items”.  If we use story points it will mean “5 story points as defined by the team”.  And if we use effort estimation it will mean “5 days of estimated work”. The same approach with different units.

This last point is particularly important.  Even if the team estimates in days of effort, I still recommend they use velocity.  A day of estimated work is not the same as a day of schedule.  The schedule will depend on the team’s estimation biases and on their loading.  Only by mapping past estimates to schedule can we get a realistic idea of what progress the team can make. Otherwise the team may estimate well in days of effort but still over-commit to what they can achieve.

Velocity then gives us a tool to assess schedule when working with timeboxes. Imagine the team has a velocity of “5” and has twenty days in the current timebox to the next release point. 

We might imagine that we would typically consider backlog items around one hundred total estimated effort (twenty days at 5 points per day).  The ones that are two hundred down the list won’t be in this timebox in the current ordering. If those lower items are critical, this should drive a conversation about backlog refinement.

Limitations of velocity

Velocity is a useful tool but it is not magic. Identifying that we might delivery one hundred points of effort does not guarantee those items will be done at the end of the timebox.  We are still in a complex environment.  Uncertainty levels are always high. 

• There is uncertainty in the estimates. 
• We also see variability in the velocity which the team achieve. 
• And finally there are potential changes in priorities. 

It is critically important to remember what velocity is for. Velocity is used to predict future performance based on past performance. However, it cannot be used to measure productivity levels. This is because there is no absolute measure of how much is created. The “points” are always an arbitrary measure using relative estimation.

Imagine a team increases their velocity from 5 to 10, or one team has a velocity of 5 and another has a velocity of 10. Is one team “better” or “faster” or “more efficient”? That may be true, but the data tells us nothing about that. One team might deliver more value, but it could also be measuring what it delivers using a different scale.

What would happen if we pressured a team to increase velocity? Undoubtedly they would deliver larger numbers, but this might be by delivering the same items assigned larger scores. That would tell us nothing about productivity. Worse still, by changing the scoring we have lost our ability to predict based on past performance.

We use velocity for prediction,
not for assessing performance

Good practices

You should ensure that each team is enabled to measure their own velocity. This will involve setting up a work management system, and also coaching the team in how to access and use the data.

You also need to educate the organisation about what to expect. Velocity is a useful tool but does not make our backlog into a predictive plan.  We should use velocity as a tool to help understand how our current ordering decisions are likely to play out.  We cannot use it to create a precise plan of what will happen and when. Nor can we use velocity to judge individual teams.