Scrum teams understand that velocity is an indicator of how much work a team can accomplish in a sprint. Velocity can also be used to forecast completion dates, using an estimated backlog and the team’s velocity to project how deeply into the product backlog a team will be at a given point in time.
Scrum estimation works because it avoids making time-based estimates, and for good reason. People are poor at estimating task-completion times; we tend to focus more on what we want to achieve, underestimating or overlooking potential impediments.
Scrum makes estimating a two-step process. Instead of estimating work on a time scale, step one sizes the work on a relative scale, comparing how much smaller or bigger one piece of work is relative to another, the premise being that people are much better at relative sizing than they are at estimating duration. Ideally, teams use relative number sizes in a Fibonacci sequence, which increase at the rate at which humans are able to easily perceive differences.
Step two uses the “CSI approach” of going where the evidence tells you. With Scrum, teams use the evidence of actual delivery to determine their velocity – how much work they can accomplish within a sprint – bounded by a couple of key constraints: delivery includes high-quality code using achieved through sustainable development.
The objective is to answer the question: “Based on my current staffing, how fast can I deliver high-quality code on a sustainable basis?” Answering this question provides the elements of predictability and forecasting that management desires. But velocity can be used for more.
It can be used as a metric for improvement. To be clear, I’m talking about an improvement metric and not a productivity metric. The focus isn’t on the output produced by the team, it is on the outcome of team improvement.
The team needs to ask itself how it can get better, what practices or behaviors they could incorporate to improve upon its current velocity – as long as it doesn’t come at the expense of doing the right things, which can happen when output is over-emphasized. The objective is to make a change and then use velocity as a metric to see if that change had a material impact on the overall performance of the team.
This is all part of the continuous improvement cycle that all teams should be embracing. You never actually reach the pinnacle of software development, but you should never stop climbing. The best are always asking themselves how they can get better.