Team Velocity Is Not as Simple as It Seems

The subject of Scrum team velocity can be confusing and controversial. My intent is not to add fuel to the fire but rather, to contribute to the knowledge base around velocity and what it represents.

The simplest way to do this is via an example.

Let’s say a Scrum team has an average velocity of 20 story points per sprint. Everyone considers that to be a pretty good number. But what does it really mean?

I’d start by asking how many sprints were completed to arrive at that number. In other words, how many sprints are we using to calculate the average? I’d also want to know the smallest velocity and the largest one to get a sense of how widely distributed the velocities are. (Excluding the first 2-3 sprints might be wise as Scrum teams often need a few sprints to sync and stabilize as a functional unit.)

These additional parameters are important. If a small number of sprints were used to calculate the average, the team may not have established a repeatable cadence as yet. If the range of velocities per sprint is very wide, I’d have to wonder if the team is operating well as a whole or simply consists of several developers working near each other.

Now it gets more complicated.

I’d also ask about story points being created during sprints. These new points could be defects or they might represent functionality that no one thought about in advance but is required before the final release. Either way, if the team completes 20 story points and creates 5, their effective velocity is somewhere between 15 and 20.

If the 5 new story points are bugs, should those points be subtracted from the sprint velocity so 20 points of calculated velocity becomes 15 points of effective velocity?

If some of the newly created points represent new functionality, it gets tricky. New functionality gets added to the product or release backlog depending on when the new functions are needed.

If a new function is critically required before the release is complete, the new points need to be added to the release backlog, thus delaying the final release date. If the new function is optional, the new points can be added to the product backlog and ignored for now. (BTW, a release consists of several sprints.)

Inevitable arguments will ensue over whether an issue is a defect or a new function. Let’s not go there.

There is also a more general argument to be made that knowingly adding to technical debt also reduces velocity. So if a developer takes a short cut in the code, he should estimate the story points needed to pay off the debt and that value should be subtracted from the team’s velocity for that sprint.

This involves a bit of a judgement call in that the team might decide not to pay off the debt anytime soon. Regardless, the technical debt exists and won’t simply go away.

Velocity is intended to be a simple metric and in principle it is. Unfortunately, nothing about software engineering for enterprise business users is truly simple. Should you track velocity? Yes. Should you reduce it as I’ve described above? Not for a new Scrum team but be aware of the issues and factor them into your retrospectives.

Oh, and please don’t try to simply compare velocities across multiple Scrum teams. That gets even more complicated!

Updated: May 10, 2012 — 10:19 pm