This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!
This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.
We know how much work we can sign up for.
Teams using iterations are supposed to finish every story in every iteration. But how do they know how much to sign up for? That’s where capacity comes in. Capacity is a prediction of how much the team can reliably accomplish in a single iteration.
Capacity is only for predicting what you can include in your next iteration. If you need to predict when a particular set of stories will be released, see the “Forecasting” practice instead.
If you’re using continuous flow rather than iterations, you don’t need to worry about capacity. You’ll just start new stories when the previous ones are finished.
Capacity was originally called velocity. I don’t use that term anymore because “velocity” implies a level of control that doesn’t exist. Think of a car: it’s easy to increase the velocity; just press the gas pedal. But if you want to increase the car’s capacity, you need to make much more drastic changes. Team capacity is the same. It’s not easily changed.
...to continue reading, buy the book!
In this Section
- Yesterday’s Weather
- Capacity and the Iteration Timebox
- Stabilizing Capacity
- Sidebar: Why Estimate Accuracy Doesn’t Matter
- Estimating Stories
- Sidebar: A Conversational Estimate
- Conversational estimating
- Affinity estimating
- When Estimating Is Difficult
- Defending Estimates
- Your Initial Capacity
- How to Improve Capacity
- Improve internal quality
- Improve customer skills
- Support energized work
- Offload duties
- Support the constraint
- Provide needed resources
- Add people (carefully)
- Capacity Is Not Productivity
- Cargo Cult: Gotta Go Fast
- Alternatives and Experiments