There are two ways of 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 .
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 planning due to the following 3 main reasons.
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 they can deliver the products.
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 total capacity of the team can be calculated as-
Team’s Capacity = number of team members * time in hours * days
= 720 hours
But planning a total capacity in this pattern may-
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.
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.
Note: It is recommended to use less Focus Factor (say 0.6), if-
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.