Capacity Planning
Intermediate
difficulty
Stage 4
Agile IQ® Level
Planning
Practices
Scrum
Framework
Introduction
One of the fundamental differences between traditional waterfall delivery and agile delivery is planning.
Waterfall
Planning is performed upfront with an entire view of scope and an end date, typically defined by management.
Agile
Planning is performed iteratively and continuously, assessing the need to adapt to emerging needs and changes. [1]
The most common practice in planning is to use velocity to determine capacity using Story Points.
Velocity as capacity
Velocity-based planning is based on the premise that the amount of work a team will do in an upcoming Sprint is roughly equal to what they have done in prior Sprints. [3] Various assumptions are made such as a constant team size, risk, complexity, similar type of work, consistent Sprint lengths, etc.
To utilise velocity-based planning the team needs to have baseline data to form assumptions around the anticipated future velocity of the team. Hence, Story Point estimation plays a greater role.
Velocity changes over time, so avoid relying on:
- The average – 50% of the time you will likely be over your capacity.
- The highest – you can only achieve this 5% of the time.
Try, instead, to calculate what velocity is achieved 80-90% of the time.
What if your team has no velocity history?
The Scaled Agile Framework® (SAFe®) recommends a normalisation approach to forecasting velocity and planning in teams [5]:
- Start with a basic 8 point per full-time team member (adjust for part-timers).
- Subtract one point per day for every team member on leave for the Sprint, e.g. public holidays, vacations.
- Don’t count the Product Owner or Scrum Master if they are full-time.
Example
Assuming a six-person team composed of three developers, two testers, one Product Owner and one Scrum Master, with no vacations, then the estimated capacity equals:
- 5 × 8 points = 40 Story Points per Sprint.
“Don’t look back”
Once the team starts Sprinting, start measuring planned versus actual velocity. Replace the old velocity with the new, actual numbers, for future planning. Importantly, don’t adjust old figures or re-estimate old Backlog items based on your new data.
capacity Versus Load
Be aware that planning out every Sprint for an entire quarter introduces significant uncertainty, even if just from the perspective of natural variability. The futher our the team forecasts their load versus capacity the more likely their estimations will be inaccurate.
Ensure that the forward plan for Sprints is adjusted each Sprint Review and expectations set with stakeholders and the Product Owner regarding what can be delivered and when.
Anti-patterns: Filling up each Sprint to 100%
People are tempted to ensure each Sprint is "full" so that the team is "fully utilised". When a whole quarter of Sprints is full, there is no room to take on feedback at the end of each Sprint. Ensure that there is some capacity to take on feedback and adapt each Sprint. If a Sprint isn't full, but the team finishes early, then it can simply take on more work directly from the Product Backlog.
References
All fields are required.
