A lot has been written about velocity in Scrum. Should we use it? How? Why? Is it OK to report velocity outside the team?

What is velocity

From now on, I’ll adhere to the following definition of velocity in the context of software development:

Velocity is a planning tool used in Agile Software development […] Velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project. Velocity - Wikipedia

Velocity is a planning tool - useful for looking ahead.

The units of work can be summed story-point estimates for completed product backlog items, or a simple count of completed product backlog items, if items are broken down into roughly the same size. Both estimates and breakdown are done by the team, because they’re the experts and best capable of estimating and breaking down.

Ideally, you’ll choose your interval to be equal to your sprint length. When not working in sprints, you can pick any reasonable wall-time interval.

If we’d compare a sprinting team to a driving car, the car’s distance covered during the trip would be the best analogy for the team’s velocity.

Velocity does not tell us we’re doing the right thing, it merely tells us we have done a certain amount of work, expressed in units whose value is solely known to and can only be influenced by the team.

When to use

Team Velocity is a useful planning tool to teams for two reasons:

• Help the team to determine how much work it can take in sprint, based on actual evidence from past sprints;
• Tracking velocity helps the team to forecast to the customers and stakeholders what they can achieve in a given amount of time based on evidence of performance in previous sprints and the current state of the product backlog.

In addition, tracking velocity might help the team to sniff out potential wasteful practices, manifesting themselves through a drop in velocity.

In my opinion, for all other purposes velocity is useless. This goes especially for reporting outside the team, more so if your team is being held accountable for their velocity

• then it goes from useless to harmful.

How to use

We identified three scenarios where velocity might be useful:

• detect wasteful practices;
• what can we do next sprint;
• forecast to stakeholders.

Sniff out wasteful practices

In the context of software development, speed is the absence of waste. High speed: good. Low speed: potentially wasteful. Tracked velocity can serve as an indication of wasteful practices, (leading to lower speeds) or removal thereof (leading to higher speeds). As such, velocity can be used as a way to measure-up.

In this case velocity is circumstantial evidence at best and the team needs additional retrospection to able to pin-point these wasteful practices.

When using velocity this way, be aware that velocity will start radiating the team’s rate of improvement. This might (unconsciously) influence the developer’s estimates. So there might be some risk here. When used only by the team, in a healthy, non-judgmental way, this might be OK.

How much work to take in Sprint

A development team that is aware of its own capabilities, can determine how much work it can take up in its next sprint with confidence. When the developers have tracked their velocity and helped providing the estimates, it will be very transparent why they commit to the work they do. Tracking velocity can help the team to become more aware of its capabilities.

Forecasting to customers and stakeholders

If a team is aware of its velocity and it has a reasonably well refined backlog, it can assist stakeholders to forecast what it expects to achieve in a given period. This might be useful in the case of marketing events, or when aligning work with other parties external to the team.

When using velocity for this purpose, don’t communicate your team’s velocity as is, instead communicate your forecast with respect to where you expect you will be in your backlog at a given moment in time when circumstances stay the same. Communicate this as a range, and involve the stakeholders in making decisions on what’s important.

The best illustration on how to provide this forecast and what questions to ask your stakeholders, is given by Henrik Kniberg in his must-see video on product ownership, “Product Ownership in a nutshell” at time 11:30:

What’s your team’s definition?

What’s your team’s definition of velocity? How have you agreed to use your velocity?