Capacity-Based Sprint Planning

There are two ways of Sprint Planning:

1. Velocity-based Sprint Planning
2. Capacity-based Sprint Planning

Velocity-based planning of the Sprint determines how much work the team can accomplish in the Sprint. In any Sprint, the velocity is calculated as the number of Story points completed per sprint. This is a basic introduction to Velocity-based Sprint planning. We will learn more about this type of sprint planning in the next section.

What is Capacity or Commitment-Based Sprint Planning?

Capacity-based sprint planning, also called Commitment-based Sprint planning, is based on the team’s available capacity (in hours) for the sprint and tries to fill that capacity effectively without overburdening and undercommitting the team members. Capacity-based planning is considered the best way of sprint planning due to the following 3 main reasons.

1. The capacity of the teams may vary from one sprint to another, depending on holidays, leaves, or other commitments. So, every sprint is not an average sprint.
2. The story points and the velocity are the two important measures over multiple sprints for estimating the release dates. But story points are found to be coarse-grained for planning the details of a two-week sprint. If you consider the hours, they are fine-grained enough and much useful for estimating concrete tasks.
3. Lastly, in the Sprint Planning, the user stories allow the development team and the Product Owner to consider each story in detail to develop a shared understanding of the end product.

In capacity-based sprint planning, a team commits to one product backlog item at a time by roughly estimating the involved tasks and finishing the task when they feel that the Sprint is full.

While planning a capacity-based sprint, it is crucial that the team’s commitment is not looked at as a guarantee. Here, commitment can be viewed as a team’s commitment to do its best. In fact, teams can perform at their highest level 80% of the time. The commitment should be something that can be taken seriously and should utilize most of the time. In this way, businesses gain confidence in what time they can deliver the products.

Who All Participate in the Capacity Sprint Planning?

A capacity or commitment-driven sprint planning meeting involves the Scrum Master, Product Owner, and all the development team members. The Product Owner presents the highest-priority product backlog items in the meeting and introduces those top-priority items to the team.

How to Do Capacity-Based Sprint Planning?

Scrum teams often face the challenges of sprint commitments during sprint planning. The challenges include:

1. How many user stories can the team commit in a sprint?
2. How to know the team’s capacity?

The second challenge is a crucial one because to commit to the sprint goal, you need to know the capacity of the current team, and the capacity can be calculated as per the team members’ availability in the sprint.

Let’s understand it with an example:

Consider a team consisting of 6 people working for 8 hours per day for 3-week sprint (15 days). Then the total capacity of the team can be calculated as:

Team’s Capacity = number of team members * time in hours * days
= 6*8*15
= 720 hours
But planning a total capacity in this pattern may:

1. Burn out the team with loads of tasks
2. Make them rush to reach the end goal
3. Hamper the quality and lead to low team morale

Then how to decide the capacity that the team can commit to? And how the team can make the sprint planning events more effective? Focus Factor (F.F) can be used to get the real capacity.

This focus factor lies in the range of 0.6 - 0.8.

What is Focus Factor?

Project Managers generally plan for 6-6.5 hours per day for executing a project. So, the focus factor is nothing but the capability of the teams to stay focused on the sprint goals without any impediments. You can get the ‘real capacity’ when you multiply the total capacity with a focus factor. E.g. Consider, focus factor is 0.6, then the real capacity of the team will be 720 * 0.6 = 432 hours.

The team can utilize these 432 hours of work in the present sprint. The team selects the highest-priority items declared by the Product Owner and divide those stories into tasks to estimate each task for hours. So, the team will pick up the stories until the time length does not exceed more than 432 hours (as per this example).

Using less focus factor, if the team members have ended up the current sprint with all the work items (tasks), they can add more tasks in that sprint. Teams can retrospect on this to check for raising the focus factor to reach a sustainable flow. Going above 0.8 can be risky and can slow down the teams too.

In case of chaotic organizations, the focus factor usually remains on the extreme left, such as 0.6 or below. The chaotic organizations show no rhythm in working. Such organizations represent factors like unplanned meetings, recruitment HR bringing someone for an interview, pre-sales emergency, not having predetermined working hours, less clarity on sprint backlog items, cluttered team structures, and so on.

Note: It is recommended to use less Focus Factor (say 0.6), if:

1. The team is new to a project
2. The team is implementing Scrum for the first time
3. The team is new to the technology domain
   

What is the Output of Capacity-Based Sprint Planning?

Sprint Backlog is the output of the Capacity-based Sprint Planning meeting. A Sprint Backlog is nothing, but a list of the product backlog items that the team commits to deliver, plus a list of tasks needed to deliver those product backlog items. Also, each task on the Sprint backlog is usually estimated.