What is Development Velocity ?
Velocity 30 seconds…
Velocity is meant to help teams predict how much work they can complete in a given time frame - typically a sprint.
Before a sprint starts the teams look at all of the tasks available to them and size each one using scales such as:
- Fibenaci: 1, 2, 3, 5, 8
- T-Shirt sizes: S, M, L, XL, XXL
If (and that can sometimes be a BIG if) the sizing is consistent then after a few sprints teams should be able to predict reasonably accurately how many tasks they can commit to a sprint. For example, a team may have been able to complete 15, 18, 16, 20 points over the last four sprints so they would commit to completing, say, 18 points when planning the next sprint.
What Velocity is good at
Cadence
It’s good for keeping teams focused on what they can achieve over a short period of time and encourages healthy push-back when Founders or Product Managers threaten that commitment by asking for a “quick” favour or moving the goal posts mid-sprint.
Managing ‘Effort’
The abstract nature of velocity makes it very good at understanding collective team effort - an XL might be 7 days for a junior dev and 3 days for a senior. Either can pick up the task because we’re measuring the collective amount of work a team can complete.
Limiting Context Switching.
Controlling context switching by ensuring that developers only focus on the work they’ve committed to completing and not switch to new things as the business demands.
What Velocity is not so good at
Predicting when things will be finished
There is a common misconception that velocity enables management to make longer term predictions on software delivery over, say, a quarter or the completion of a project. Velocity only works as far as tasks have been broken down and sized by the team. This is rarely more than a few weeks of work.
What went wrong…
The Fibenaci Number or T-Shirt size is completely abstract and can only be used to monitor trends. If your sprints are 18, 20, 17, 20, 5, 8 then clearly something has started to go wrong but velocity won’t tell you what.
Measurement of Work Done
Similarly abstract velocity won’t highlight long term changes such as technical debt. Over the course of, say, a year the same team may continue estimating the same amount of work per sprint but technical debt may start to slowly reduce the work they complete. The team will subconsciously adjust their estimates and the same velocity will eventually represent much less work but there is no way of telling that.
It’s toxic in the wrong hands
If you think of velocity as an abstract representation of mostly immeasurable factors:
- Complexity of code
- Technical Debt
- The size and skill of the team
- The morale of the team
It’s easy to see that two different teams will estimate in very different ways. In fact move a team to another code base and they’ll probably start estimating in different ways too - velocity is a number built on inutition and experience not calculation. Some managers like to compare the output of different teams using velocity. It’s not just wrong, it’s extremely toxic.
Real life stories about Velocity
“I once had to intervene when a ‘manager’ had noticed that a particular developer’s personal velocity had dropped. It dropped because this person was being helpful by taking on the more complex, tech-debt ridden tasks to help out newer members of the team. You could argue that the tasks should have been sized better but the problem with complexity and techn ical deby is that it makes estimation hard and the varience in accuracy much greater.”
“a late night email from a founder that I had foolishly explained velocity to. He’d had calculated individual velocities of each developer and sent me a detailed plan of everything each individual would be doing for the next ten months…”
“Started work at a company already doing some basic sprint and velocity. Most sprints they achieved 80% of the commitments. Management complained to me of things not being delivered but engineering keot pointing at these velocity charts. Digging a little deeper tasks were taking an insane 50-60 days to be delivered and velocity was counted as the tasks delivered in the last sprint even though they were started 2 or 3 sprints ago. Basically the team had become good at accurately predicting very slow delivery.”