How to do Sprint Planning
22nd Jan, 2020
There are so many questions when we try to do a Sprint Planning. Some of them could be,
- How much work can the team do within a sprint?
- How to decide the amount of work to be done?
- If we do not have velocity, how to plan for the first sprint?
- How many Sprints do we plan at a time?
So many questions arise and it is quite confusing on how to start when we do not have any data upfront.
Planning is a vital part of starting the sprint. It clarifies the part on what is expected out of this sprint through a Sprint Goal and also a plan in the form of Sprint Backlog.
Sprint Goal helps us understand the purpose and Sprint Backlog guides us on how to achieve the goal.
There are two ways to do Sprint Planning, and they are,
- Capacity based
- Capability based
Capacity Based Sprint Planning:
The team identifies the collective capacity of the whole team. Based on this, the team can choose the work by collaborating with the Product Owner to achieve business needs.
Identifying the capacity will help the team decide how much work they can do based on their capacity.
For example: If there are 8 Development Team members, and each person is available for 8 hours a day. Per day, the team capacity is 64 hours. If your Sprint is two weeks (or ten days), as a team, you have a total of 640 hours. Hence, the team can plan the work for 640 hours for this Sprint.
When the team is deciding their capacity, they will also take holidays, leaves, and the availability of team members in the sprint.
Capability-Based Sprint Planning:
In capability-based Sprint Planning, the teams do not talk about the time they have. Instead, they run experiments.
Based on the historical data of the team's capability, the team plans for the Sprint, keeping business needs in mind. Capability means how much valuable work the team can deliver in a fixed amount of time - the Sprint.
For example: If the team is working for the very first time, the team does not have any historical data of their capability. The team can run the first Sprint as an experiment.
Use the outcome of the Sprint as a pointer for planning the upcoming sprint. One way to do is by using
- How many Product Backlog items "done" in a sprint?
- How many story points delivered in the sprint towards the vision?
If the team uses different ways of estimating other than story points, then that will be used for capability planning.