Capacity in Sprint
Capacity in Sprint
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 .
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 under committing the team members. Capacity-based planning is considered the best way of sprint
1. The capacity of the teams may vary from one sprint to another, depending on holidays, leaves, or other
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 the confidence of in what time
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.
Scrum teams often face the challenges of sprint commitments during a sprint planning. The challenges
include-
The second challenge is a crucial one because for committing to the sprint goal, you need to know the
capacity of the current team and the capacity can be calculated as per 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 weeks sprint (15 days). Then the
= 6*8*15
= 720 hours
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.
Project Managers generally plan for 6-6.5 hours per day for executing a project. So, focus factor is nothing
but the capability of the teams to stay focussed on the sprint goals without any impediments. You can get
the ‘real capacity’ when you multiply 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 this 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 the 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.
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.