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?
And now?
Just something to think about…
agile capacity collaboration dependent teams productivity release plan roadmap scrum teamwork tech debt timebox velocity
6 Responses
for me velocity is the story point completed at the end of sprint. where delivered means one which meet acceptance criteria and DOD and not all story/feature what team has worked on. The story which do not move to Done and not accounted for velocity.
Logic – Velocity helps with predictability of what team can deliver to market , which further helps in market commitment from PO /PM/Sales/organization.So the one not meeting DOD are not counted.
Please discuss if you have a different opinion.
Thanks for the thoughts. I agree with you but caution one thing that I mention in the article. If our PO (or other leadership) takes our points we finished per sprint to forecast ahead without taking the type of work that comprises the sprint into consideration, that’s where expectations are confused. When a lot of us look at forecasting, we’re looking at when we can get something new done – e.g. 10 points of new feature work.
If what our team gets done during a sprint is 10, the expectation would be that in one sprint the team would have said feature complete. BUT that does not account for the other types of work that go into our sprints (tech debt, defects, unexpected complexities).
Regardless of what we call it – we need to understand what types of work are making up the total number of points the team completes per sprint. Then we can more transparently forecast as to when something will be delivered (in above example, the 10 points would probably take two sprints because hopefully the team is also doing some technical debt work and keeping their defects in check which takes some of the point allocation).
Definition of done is very important as well. You have hit on something that is hard for people to accept. If it does not meet the DoD by the end of the sprint timebox, it does not count toward our points completed in the sprint. No partial credit because partially done work can lead to waste very easily.
Maybe it’s time to dispense with velocity.
I don’t teach it anymore. If you deliver constantly, velocity becomes inconsequential. At one time, years ago, it had some usefulness, but it has become at once abused and misused. Adaptive planning is needed more than velocity.
“When will we deliver the product? Really damn fast!” Remember that agility is ability to “turn on a dime for a dime” – fast and cheap.” With change coming fast, velocity is about removing waste and local optimization in the organization so change can be done fast and cheap
Way too many organizations neglect this necessary change and the claim to “do agile,” whatever the hell that means. It usually means something like “we want development to go really fast doing things as we have always doe them. We certainly don’t want to change our org structure. We like local optimization!!”
The term “agile” is so misused, abused, misunderstood, and messed up that I don’t even use the term anymore. “Magic” is now its definition.
[…] Natalie Warnert distinguishes between capacity and velocity and explains why the difference matters. […]
[…] For some additional illustrations that drive home the point, you can view the original post here: http://nataliewarnert.com/capacity-versus-velocity/ […]
[…] is a good follow on to the velocity and capacity discussion. If velocity is the amount of new feature work we can get done in a sprint and capacity is the […]