Many well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working or how much they are producing. Neither of these is correct. Velocity is a tool for predictability.
Because of this misunderstanding, many managers think that the team should work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Imagine that your manager wants to see the team’s velocity increase. This is very easy to achieve; the team can simply increase their story estimates over time. 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. What’s a scrum master to do?
Faced with a manager who wants to track velocity, 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.
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 of 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 whose 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.