Capacity Planning



Stage 4

Agile IQ® Level






One of the fundamental differences between traditional waterfall delivery and agile delivery is planning. For the former, planning is performed upfront with an entire view of scope and an end date, typically defined by management. For agile, planning of performed iteratively and continuously assessing the need to adapt to emerging needs and changes. [1]

The common practice is to use velocity to determine capacity.

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, similar type of work, consistent Sprint lengths, etc.

To utilise velocity-based planning the team needs to have base line data to form assumptions around the anticipated future velocity of the team. Hence, Story Point estimation plays a greater role.

velocity trends for agile iq product

Velocity changes over time, so ensure you don’t use:

  • The average – 50% of the time you will likely be over your capacity.
  • The highest – you’ll overload the team 95% of the time.

What if your team has no velocity history?

The Scaled Agile Framework® (SAFe®) recommends 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.
  • 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.

capacity Versus Load

Armed with their capacity at Sprint Planning, teams can then use Story Point estimation to determine the size of work and add it to the Sprint Backlog. When the load nears capacity the team is “full” and stops brining any more items in. In SAFe®, teams forecast the entire Program Increment (PI) consisting of at least 5 Sprints.

Be aware that planning out 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 mor elikely 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.


1. Sutherland, J. & Schwaber, K. (2020) The Scrum Guide.
2. Cohn, M. (2014) Capacity-Driven Sprint Planning.
3. Cohn, M. (2014) Velocity-Driven Sprint Planning.
4. Cohn, M. (2014) Why I Prefer Capacity-Driven Sprint Planning.
5. Leffingwell, D (2021) Iteration Planning.

All fields are required.

Your user code appears in your user profile. It is a 12-digit key with spaces between each set of four characters.
Your Agile IQ® ID is your 12-digit subscription key.


agile iq academy logo 2022-05-05 sm

Enter your details

search previous next tag category expand menu location phone mail time cart zoom edit close