Scrum teams rely on metrics to inspect and adapt. Taken too far, the metrics tend to lose value and in some cases cause harm.
[featured-image single_newwindow=”false” alt=”Robert Donovan | Velocity | Flickr.com” title=”Robert Donovan | Velocity | Flickr.com”]Robert Donovan | Velocity | Flickr.com[/featured-image]
Last week I wrote about 5 agile metrics to measure high-performance scrum teams. At the top of the list was the most controversial metric that scrum teams use: velocity. This seemingly simple metric is just a measurement of how much effort a scrum team can complete within a given sprint.
Velocity is – in its simplest form – the sum of the story points completed in a sprint.
The temptation that many organization face is to turn velocity in to a performance metric.
For instance, I was recently asked what I thought about setting an objective to increase the team’s velocity by 10% by the end of the year. My answer: It’s a terrible idea.
- Encourages gaming: An intelligent scrum team will realize that if they gradually inflate their estimates over the course of a year they will hit their 10% objective – WITHOUT delivering more value to the organization.
- Increasing velocity is not the goal of scrum: We are interested in delivering valuable, high quality software to our companies in a sustainable way. How does a 10% increase in velocity get the scrum team there?
- Quality suffers as a result: A scrum team that is forced to increase velocity will have to make tradeoffs to complete the additional stories required to get the numbers higher. Quality inevitably suffers when these types of decisions are made.
- Lots of unknowns: Scrum team members leave the company, they get sick, and go on vacation. An estimation can also be way off – it is an ESTIMATION. If the scrum team learns something new about a story, velocity can dramatically go up or down.
Another idea that managers try is to compare the velocity of one scrum team with another. This is usually an attempt to normalize velocity across multiple scrum teams. It’s a meaningless comparison as scrum teams have different skills, goals, tools, and approaches to estimating work.
Flame wars often flare up over questions like: “Does a scrum team get credit for the story points related to bug during a sprint?”
Some scrum team members say, “Yes! We did the work and it should show on our velocity.” Others say, “No way, you already got credit for that story and are now cleaning it up. No double dipping!”
Mike Cohn did a great job of answering the question here. Essentially, he says pick whichever way makes sense to your team and be consistent. Easy, right?
Questions like these come up regularly and show a general lack of understanding of how velocity should be used.
Velocity is a limited metric that can only tell you what you achieved in the past and could possibly do in the future. During sprint planning it can help a team avoid over committing. During a sprint retrospective an up or down trend in velocity could lead to a discussion about the team’s definition of done or other team practices.
And there is the value that comes from tracking velocity. It is in the conversations that it causes the scrum team to have. These discussions are opportunities for the team to inspect and adapt their practices. The new insights will hopefully lead to more valuable, working software being delivered to the organization.
Which is important because according to the Agile Manifesto, “Working software is the primary measure of progress.”
[reminder]Which metrics do you use to drive conversations on your scrum team?[/reminder]