We talk about how using Agile practices help us deliver business value faster because they let us focus on doing the right things faster as well as doing things like incremental releases.
Unfortunately, there’s a dark side that often comes along with this (and, in some organizations, ends up being the driving force instead of a bad side effect) – an obsession over velocity. Velocity, for those who aren’t familiar, is the number of points/cards/features/etc that a team ships over the span of a single sprint.
A lot of managers will obsess over this number and either expect it to go up constantly or to remain steady no matter what. I’ve literally seen managers who have dragged entire teams into meetings that were focused around “wanting to get to the bottom of” why the team’s velocity dropped from one sprint to the next.
Part of this obsession comes from the fact that velocity is a number that they can point to in order to prove that they are working or pushing their teams to do ever increasing amounts of work (please don’t do this. It’s unhealthy). Your manager usually has a quarterly or year end review just like you do and they want to be able to point to something concrete.
A lot of managers work on the maxim that you need to be able to measure basically everything for it to be of any value. In fact, many of them will use a quote that they attribute to W. Edwards Deming – “if you can’t measure it, you can’t manage it.”
The problem is that that isn’t the quote. The actual quote is “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.”
That’s… a little different from what so many managers repeat – which they have usually gotten from someone else in a game of managerial buzzword telephone.
Now, that’s not to say that measuring things which can be measured is useless. It can be incredibly useful if you do it for the right reasons – and being aware of a team’s velocity is no different. Done right, it can provide valuable feedback and help guide your practices as a team or even an organization.
We’ll get to the right reasons to look at velocity in a second, but first I want to make a statement that a lot of people who offer agile coaching services (and certainly a lot of managers) will vocally disagree with me on.
Velocity, as a metric, will tell you almost nothing useful in the moment. It is, at best, a far trailing indicator. You can’t walk in on Tuesday morning and say “Yup. They’ve shipped 3 points worth of software. They’re on track.” You can’t really even do that at the end of the sprint.
Velocity is really only valuable in the aggregate. A single velocity reading isn’t really worth anything.
That gets us to what the right reason to look at velocity is – detecting significant swings in velocity can give us a little insight into the health and flow of a team.
By significant, I don’t mean a few points. If your team varies a few percent from sprint to sprint, that’s pretty normal. What we’re looking for here are fairly large swings, and we want to find them in both directions – upward and downward.
A significant increase in velocity can indicate a number of things including:
- Your team is starting to gel
- Your team is getting a handle on a new process that they’ve been learning (TDD for example)
- Your team is really starting to get their heads around the problem domain
- Your team (both business and technical) are having better conversations about the value that’s really needed so are doing less rework
On the downside, it can also mean that they really over-estimated the complexity of the stories that they were working on (possibly to impress management by “shipping lots of points”).
A significant decrease in velocity can, among other things, suggest:
- Your team has underestimated the complexity of the things they’ve been working on (a lot of teams do this sometimes)
- Your team has encountered some issue that has caused work to stop or slow down temporarily like a production or infrastructure outage
- Your team has needed to rework more things than normal or has discovered defects that needed to be fixed
- Your team has needed to spend time to modernize a section of a legacy codebase that wasn’t previously under test
- Your team’s morale has taken a hit for some reason
Of course, it could also be that someone went on vacation, someone left the team, or you got new people on the team and time was spent getting them up to speed.
So what do you do with this information?
When you’ve found out what caused the swings in velocity and ruled out the noise of things like “Rachel went on vacation” or “We accidentally over/under-estimated a series of stories”, you look at a couple of things:
- What caused us to speed up (higher velocity)
- What caused us to slow down (lower velocity)
As a general rule, you want to do more of the things that speed you up and find ways to mitigate the things that slow you down.
Seriously. That’s it. That’s the best use of velocity – to be alerted when things change significantly so you can figure out what changed and how best to deal with it.
So stop beating your teams up if their velocity drops a little. Instead, figure out why it happened and what you can do as a group to fix it. And, for the love of all that’s decent, stop using it as an achievement in your year end reviews because, in that sense, it’s worthless. Focus on business value instead – after all, that’s what helps keep the lights on.