Capacity Allocation

51 team-capacity-allocation

Capacity Allocation is a necessary step which helps ensure that investments are balanced across conflicting needs. To maintain velocity, teams make a decision about how much of their total effort can be applied for each type of activity in an upcoming Program Increment.

Explore More.

Related Mindset:

Lean-Agile

Operational Excellence

Segment:

Team

Inputs:

A backlog containing activities which can be divided into three types: user stories, refactoring tasks, and maintenance, as well as historical velocity for an agile team.

Outputs:

An agreement where the team determines the percentage of resources to distribute to each type of activity as well as a velocity target for the agile team.

The longer an agile team works together through the sprint cycle, the more accurate the prediction of their velocity for a future sprint.

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.

Common Pitfalls

Adopting Capacity Allocation doesn’t guarantee that problems will not occur, which can cause a derivation from the ideal implementation:

  • Product manager’s pull the team to over-prioritize new features and defects - By allocating too much time to building new features and fixing defects, a team’s velocity will slow and they can become buried by technical debt.
  • Engineer’s pull the team to over-prioritize technical debt - By allocating too much time to refactoring efforts, redesigns, and technology upgrades, a team’s velocity will decrease and Digital Value Delivery will suffer.
  • Not revisiting Capacity Allocation after each program increment - After each program increment, velocity and the context of the project can change. It is a good idea to revisit and adjust the Capacity Allocation, ensuring the proper balance necessary to attain product health and value delivery.