Velocity – Gross vs. Net
Velocity is where theory and practice clash very hard. Your numbers may look great but your predictability is worthless – or vice versa.
When you start with any agile practice, velocity seems like the easiest, most magical part. You keep count of your number of tickets to make forecasts about when more will be done. And it works! It's baffling how easy forecasting is with this method.
Until it isn't. Unplanned work appears out of nowhere, the team has to handle lots of interruptions, a surge in bugs after a release, any of a number of circumstances that make forecasting by number of tickets unreliable.
A few years ago I worked with a team on a mobile app generator. They had a stable velocity and were quite good at forecasting until the product hit a wider audience. Suddenly a lot of requests from the fulfillment team caused interruptions and because those were hard to predict they wreaked havoc with our planning. Focusing on counting backlog items and then moving to estimation of those fulfillment requests helped keep our velocity stable – after all, we were still doing the same amount of work, why wouldn't it be? – but our commitments and forecasts went down the drain.
More recently one of my teams faced the challenge of building a disruptive product from a very unclear product vision with lots of uncertainties and changing requirements. We ended up having to redo a lot of stories that we already considered done. What to do in that case? We tried reestimating stories, reopening them with the same estimation, creating new stories instead, but we still couldn't get to a confident forecast.
Both teams struggled with gross vs net velocity.
It's an extension of the concepts of planned and unplanned work. Following the book “The Phoenix Project” there are actually four kinds of work, but still only one is planned. Gross velocity encompasses all kinds of work and at least hints at how the team is doing in terms of flow, skill development and Muda, wasteful activities. But forecasting only concerns itself with how quickly a plan can be realized. So only planned work should be factored in.
The app generator team tried to keep their gross velocity stable by including unplanned work, estimation and all, and when they realized their forecasts didn't match velocity, they even experimented with buffers. But even those didn't help, because the interruptions were too unpredictable. When we started analyzing the split between planned and unplanned work, we finally had a breakthrough that helped come to a more predictive, if less stable, value: Net velocity.
The disruptive team was in a different, but similar situation: They tried lots of ways to make the numbers fit their preconception: We're doing a lot of good work, so our velocity should be high an stable. With this in mind, they tried to factor in everything they did but never hit any sprint goals. They always took in too much, based on their velocity. Similarly to the first example, even when they tried leaving a buffer it didn't help much.
So again, I turned to net velocity and excluded all bugs and external requests from the metric but that still wasn't enough to notably improve our forecasts. Only when we started to exclude bugs, external requests, rework and stories we missed during planning, did we arrive at a useful number for meaningful forecasts.
While gross velocity has its uses, it's really net velocity you want to look when you are trying to do reliable forecasts. To predict how quickly your team can work a plan, focus only on how quickly planned work was delivered in the past. Anything else will mislead and require you to artificially pad your numbers. And it still won't get you good results.
Net velocity is no silver bullet, but I find it does the job better than any other metric.