Capacity versus Velocity
We have a problem. Ok, I have a problem. I’m realizing velocity is often being used as a synonym for team capacity. In fact, I’ve done it, too. Don’t think that’s a problem? Well it impacts our forecasting, estimation, team health, and organizational expectations.
I define velocity as the amount of new work we can deliver in a given sprint against a product roadmap (i.e. new features, enhancements etc.). Capacity however is the team’s entire capacity for what they can deliver in a sprint. What’s the difference? A team usually does not only do new feature work in a sprint unless it’s an absolutely new product. And if we do not look at all the types work they do, the PO may over-forecast the team’s appetite for new feature work which has adverse effects down the line.
There are a few different types of work a team may be doing in a given sprint and new feature work (velocity) is only one of them. When I say my team’s velocity is 20 points, it means my team can do 20 points of new feature work in a sprint. However, my team is also doing work on technical debt, defects, and other overhead (think emails, town halls…). My team’s capacity (the amount of total work they can do in a sprint) is really about 27 points. (20-30% of my team’s work is not directly allocated to new feature development – a good ratio IMO).
Sounds simple but if the delineation is not understood, we are going to be over-committing to some types of work while not adequately understanding other types of work. If our PO thinks that our velocity is 27, she may forecast us to 27 points each sprint on her roadmap. That’s not a good thing because that is signing the team up for failure and customers/stakeholders up for disappointment. Yes, the team should have an input in the roadmap (and we should have tech debt in the roadmap, too), but if expectations are already set before they see it, that’s a problem. It’s hard to take something away that has been discussed (humans are excitable and don’t like change! strange, right ;).
Additionally, even if my team’s velocity is right at 20 points and that’s what the PO forecasts for the sprints in the release, that’s not leaving the team any buffer time for new features that take more to develop, design, and test that estimated (remember, when we estimate we’re often wrong but it’s a good practice for most teams) or other work that can pop in. I’m not going to get into estimating defects and tech debt here – that will be saved for another post – but the point is that we too often over-commit (I know I do in almost everything – especially cleaning my apartment) and under-deliver because we do not think about risk and complexity enough in our plans. And our plans suck – it’s not the plan we need but the act and conversation of planning.
So what do we need to know?
- Velocity <> capacity
- Sprint work (capacity) = new feature (velocity) + tech debt + defects + overhead + unknown
- Release plan should not commit teams to full capacity of new work
- If you run out of work to do you can always pull in more (if the team agrees that it can get to DONE in the sprint) – in my experience this doesn’t happen as much as we’re afraid it will.
- Both velocity and capacity can change based on many factors
A couple helpful graphs to help visualize from my friend, Aaron Kopel:
This team is predictable, right?
How about now?
Just something to think about…