Capacity Planning



Stage 4

Agile IQ® Level






One of the fundamental differences between traditional waterfall delivery and agile delivery is planning. 


Planning is performed upfront with an entire view of scope and an end date, typically defined by management.


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 trends for agile iq product

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.


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

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 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.


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