Should Management Use Velocity as a Metric?

Many well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working. That’s not what it is at all. Velocity is a measure of the rate at which the team is delivering stories. If the team worked long and hard on 5 stories but delivered none, then their velocity is zero.

Because of this misunderstanding, I find managers who think that it is important for the team to work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Faced with a manager who wants to track velocity as a management metric, a scrum master needs to identify what the manager is trying to measure, and what business decisions they expect to make with that data. The scrum master can then help the manager find more effective ways to get the data they need to make their business decisions. If the manager wants visibility into how healthy the team is, or perhaps how productive they are, we can provide them much better metrics. Trying to use velocity for these purposes won’t work.

Imagine that you are on a team, and your manager wants to see the team’s velocity increase over time. This is very easy to achieve, the team can simply increase their estimates for the user stories. Velocity will climb as high as anyone wants. This won’t correlate to any change in productivity or business performance, and the manager won’t get what they wanted. Worse, the team has just lost visibility and control of their schedule.

Velocity is a great tool for predicting what the team can deliver in the future, so long as the story points aren’t being inflated. If a user story that the team estimates as five story points today is not approximately as much work as five-point stories estimated in the past, then predictability is lost. Everybody loses.

So what is a better management metric? Number of stories delivered. It’s imperfect, as all metrics are, but it is much better than velocity. Measuring the number of stories delivered per sprint will drive a number beneficial behaviors, and gives a manager a better window into the health and productivity of the team. When a story is done, the team has delivered value to the business. This is what the business wants. Think about it. The business exists to create value, not to create busy people. When we measure the number of stories delivered, we are measuring the rate at which the team is delivering value. More stories delivered means more frequent delivery of value.

So what if we game the metric? Remember, that to game velocity the team inflates estimates. To game the number of stories delivered, the team will break their stories down into smaller stories. There are many benefits that come when the team works on smaller stories. Smaller stories are easier to understand and thus easier to implement correctly. Smaller stories will get delivered more frequently, which allows more frequent feedback. The team will get more frequent product feedback from stakeholders, so they can make more timely adjustments to the product. More frequent story completion means the team will update their burn down chart more often, and have much better knowledge and control of their schedule. Smaller stories also mean the variance in the team’s velocity, the natural up-and-down swings, will be smaller. Additionally, the more frequently the team delivers functionality to users, the more frequently they can inspect and adapt their architecture, design and technology choices. I’ve previously written about how to break big user stories into smaller user stories. Might the team go overboard with this? I’ve never seen it. I’ve worked with hundreds of teams and I’ve never once encountered a team who’s on-going problem was that their stories were too small. On the other hand, most of the teams I coach are having problems because their stories are too large.

So measuring number of stories delivered leads to smaller stories, which increases the rate at which the team is delivering value and also speeds up the various feedback loops that keep the team building the right things. Everybody wins.

Cheers,

Chris Sims

This entry was posted in agile, project management, scrum. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>