The Art of Agile Development, 2nd Edition

Capacity

AUDIENCE

Developers

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 “Forecasting” 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.

NOTE

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.

Yesterday’s Weather

Capacity can be a contentious topic. Customers want the team to deliver more every week. Developers don’t want to be rushed or pressured. Because customers often have the ear of the team’s sponsor, they tend to win…in the short term. In the long-term, when teams are pressured to commit to more than they can deliver, everyone loses. Reality prevails and development ends up taking longer than expected.

To avoid these problems, measure your capacity. Don’t ...