Currently set to No Index
Currently set to No Follow

Formal Capacity Planning

Basic

difficulty

Stage 4

Agile IQ® Level

Sprint Planning

Event

Introduction

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 the latter, planning of performed iteratively. [1] The two common variants for iterative-based planning are capacity-based and velocity-based planning.

Capacity-Based Planning

Capacity-based planning is based on the premise that the team selects work during Sprint Planning based on their expected capacity for that Sprint. The Product Owner brings the top-priority Product Backlog Items into the meeting and describes to the team, usually starting with an overview of the set of high-priority items. Following that, team members select work to bring into the Sprint not exceeding their capacity. [2]

The focus in determining scope using capacity-based planning relies less on Story Point estimation and more team judgement. Story Points can be used as a sanity check for both Sprint scope and estimations.

Velocity-Based Planning

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.

The Team Determines Sprint Scope

Whether using capacity-based or velocity-based planning, these methods differ from traditional milestone-based planning as the team determines how much work can be done and not management. This is both a process a cultural change for most organisations adopting agile practices. When planning is done by management decree it is less likely that teams will deliver work to plan.

Should I Use Velocity Or Capacity-Based Planning?

Short-term planning such as for a Sprint lends itself to suit capacity-based planning, as velocity tends to be variable and provide a less accurate forecast for a given Sprint. For longer-term planning, such as over several Sprints or several months, velocity-based planning is more suited as it relies more on average delivery rates (where work is less known). [4]

As always, commit to one approach then review regularly at retrospectives. If your method of planning is not providing desired results then consider deliberate change.

Things to watch out for

  • Velocity estimates may vary greatly for newly formed teams.
  • Velocity estimates may vary greatly for novel work that teams have never done before.
  • Older velocity data may no longer be helpful in estimating work for a Sprint. [4]
  • Velocity will be impacted by staff movements (e.g. not at work, change in team members, public holidays).
  • Velocity may be positively or negatively impacted by a change in work conditions (e.g. 100% remote work).

Actions to try

  • Collect and report velocity data in a consistent manner.
  • Collect data on aspects that may influence velocity data (e.g., incomplete work at end of Sprints, staff unavailability).

References

1. Sutherland, J. & Schwaber, K. (2020) The 2020 Scrum Guide (TM). https://scrumguides.org/scrum-guide.html
 
2. Cohn, M. (2014) Capacity-Driven Sprint Planning. https://www.mountaingoatsoftware.com/blog/capacity-driven-sprint-planning
 
3. Cohn, M. (2014) Velocity-Driven Sprint Planning. https://www.mountaingoatsoftware.com/blog/velocity-driven-sprint-planning
 
4. Cohn, M. (2014) Why I Prefer Capacity-Driven Sprint Planning. https://www.mountaingoatsoftware.com/blog/why-i-prefer-capacity-driven-sprint-planning
 
search previous next tag category expand menu location phone mail time cart zoom edit close