By looking over several sprints, the team can calculate a velocity based on story points. This velocity is the basis for Capacity Allocation, as it describes the amount of work the team can accomplish in any sprint.
To maintain this velocity, all teams face the issue of how to balance new feature development with maintenance and refactoring. Placing too much emphasis on building new features and new user stories will eventually lead to slowed velocity because of the ever increasing amount of technical debt.
Capacity Allocation is used to reduce this issue by defining a policy on how to balance team efforts over a defined period towards the three types of backlog activities: user stories, refactoring tasks and maintenance (which will include defects and platform upgrades). Highest priority items for each type of activity are then included in each increment. The percentage allocated to each activity can be modified over time to maintain long-term product health for optimized Digital Value Delivery.
Here is an example agreement for Capacity Allocation:
- Percent allocated - We agree to the percent of velocity devoted to each type of activity at the beginning of each program increment.
- Refactor, technology upgrades - We agree that the agile team has the authority to prioritize refactoring efforts, redesigns and technology upgrades.
- New features, defects - We agree Product Management has the authority to prioritize new features and defects work.
- Economics - We agree to jointly prioritize work based on economics.
- Customer value - We agree to collaborate and sequence work in a way that maximizes Digital Value Delivery.