Do’s and Don’ts of Sprint Planning
Sprint Planning is an important event in the Scrum framework that determines the deliverables of a Sprint and how they will be achieved. The Sprint Planning is done with the collaboration of the whole Scrum Team, including the Scrum Master, the Product Owner, and the Developers. However, other people like Stakeholders and sponsors may also be invited if their advice is required or felt necessary. In Scrum, a Sprint is a fixed period in which the entire work must be done. Let us learn in detail what Sprint Planning is.
What is Sprint Planning?
Sprint Planning is done to set up a Sprint where all the work is to be done and the method or process of doing it. Here the Scrum Team identifies the Product Backlog items they would work on and discuss and prepare a plan for completing them. Sprint Planning focuses on three essential things.
Why the particular Sprint is valuable: The Product Owner describes how this Sprint can add value to the product. The entire Scrum Team then makes a joint effort to set a goal for the Sprint that will convey the value of the Sprint to the Stakeholders.
What and how much can be achieved in the Sprint: The Developers and the Product Owner discuss and choose the items from the Product Backlog that must be included in the Sprint. The Scrum Team may further filter these items to increase understanding and boost the team's confidence. As far as deciding on how much can be done in the Sprint, it may be a little tricky. However, if the Developers are clear about how they have worked in the past, knows how much their capacity would be enhanced in the immediate future, and how they define what is done, they would be better equipped for Sprint forecasts.
How will the selected backlog items be completed: It all boils down to this one. Here the role of Developers becomes critical. They have their Definition of Done. So, they plan what needs to be done to build an increment that will fulfill this definition. They usually do it by breaking the Product Backlog items into smaller workable parts of one day or even less. It is left entirely to Developers' discretion how they break the Product Backlog items into Incremental value. The time duration, called the time box, is also decided for the Sprint. Generally, a timebox of 8 hours is set for a one-month Sprint. If the Sprint is shorter, the timebox is also shorter.
The goal set for the Sprint, the Product Backlog items selected for the Sprint, and how they would be completed together are called a Sprint Backlog. In Sprint Planning, the entire Scrum Team focuses on value. While the idea of Sprint Planning is simple, sometimes the Product Owners and the Scrum Masters cannot prepare and execute the Sprint Planning correctly. So, knowing what should and should not be done during Sprint Planning is essential. We have put together some dos and don'ts for Sprint Planning, which could be very useful in successfully executing Sprint Planning.
Do’s and don'ts of Sprint Planning
Do’s
Prepare and prioritize the Product Backlog: For Sprint Planning, you need to have a Product Backlog. But before you start planning, you need to prioritize the Product Backlog items. This is done by the Product Owner on the value of each Product Backlog item by refining them. This is important for removing uncertainties and identifying dependencies.
Timebox the meeting for Sprint Planning: Depending on the Sprint duration, timebox the meeting for Sprint Planning. Usually, 4-8 hours is the standard for a Sprint of 15 days to one month. You have already set the priority for the Product Backlog items. Now reiterate the items with the highest priority and features.
Discuss team velocity and review team capacity: Team velocity may not necessarily determine team capacity. First, the team's velocity is discussed to see how much work can be completed in the given time. But a team's velocity may help in good prediction about the completion of the Sprint. But it is so only when the team works consistently, and there are no changes in the team. However, if changes are foreseen in this, then the team capacity is reviewed in terms of the hours needed. So, the team's velocity and capacity are checked during the Sprint Planning. This saves time later.
Create a Sprint Goal: This is the task of the Product Owner. Here, the Product Owner briefly describes what is aimed to be achieved at the end of the Sprint and presents the prioritized Product Backlog items. Then the Scrum Team discusses how much can be achieved based on the Definition of Done and creates the Sprint Goal. The Sprint Goal is worded and unambiguous. This is done by having a prioritized Product Backlog. However, if need be, the team can clarify the most critical Product Backlog item from the Product Owner and build a Sprint Goal around it.
Break powerful stories into smaller ones: After creating the Sprint Goal, important stories are broken into smaller ones to complete them within a Sprint. The Developers breaks the stories into multiple small tasks keeping in mind the technical work required to complete the Sprint. These may include development, testing, etc. The team may create as many tasks as it feels it can handle easily. The purpose is to keep the tasks transparent.
Estimating the task: The next thing to do is to estimate the task. The individual members of the team are assigned the tasks, and estimation is done based on their skills and experience, as each member may have different skills and levels of experience. The estimation is done in the effort required in hours. The team may further break the sub-tasks into more than one. The capacity tracker is updated regularly with hours.
Spread the risk along multiple Sprints: It is always better to spread the risk evenly across multiple Sprints. Putting too many high-risk stories in one Sprint may increase the risk, and the team may face difficulties. Spreading risk across Sprints means all Sprints will have almost equal ease or difficulty completing.
Refer to Definition of Done: The Definition of Done is understanding the whole Scrum Team about what Done means for them. And as the team gains more understanding of the product and its technical skills, this definition expands. When the team refers to the Definition of Done, they know how much work can be planned for a Sprint. So, revisiting and revalidating the Definition of Done becomes essential.
The team's commitment: A general commitment from all the team members should be obtained to complete the stories in the Sprint. Start adding stories to the Sprint Backlog. This should be continued till total capacity is utilized. If there are still some stories left in the backlog, which is not unusual, revisit your Sprint Goal. If need be, you can modify the goal so that the goal and the team commitment are aligned. It can be the other way around too. It can be that all the stories have been used, and still, some capacity is available. In that case, the team may take up some non-user stories to ensure that the capacity is fully utilized.
These were the dos. Now let us have a look at the don'ts of Sprint Planning.
Don'ts
Do not assign work: Team members should volunteer for specific tasks. The Scrum philosophy is about self-organization. So, let the team not assign work to its members. It should be collective ownership of the team, although some members may steer specific tasks based on their competence. So, the emphasis should be on collaboration.
Do not overlook the team velocity: Do not try to pack too much into a Sprint. Trying to do more in a Sprint than the past team velocity may lead to confusion and complications. So, do not push the team to deliver more as it may lead to a loss of morale in the team, or it may inflate the story point, both of which would not be beneficial.
Don't include large backlog items: There is no point in including huge Product Backlog items as completing the Sprint will be challenging. The team may struggle with large story items, and productivity may be hampered. So, it is essential to pick the Product Backlog items judiciously.
Don't turn up without backlog item preparation: The team must spend time preparing the Product Backlog items; otherwise, the planning meeting may take a long time which may frustrate the team members. So, it is always better to have backlog refinement before the planning session so that you have ready items for planning.
Do not ignore the team capacity: Do not take individual capacity for the team capacity. Story points are there so that work of the whole team can be estimated and not for setting the capacity of individuals. Establishing individual capacities may split the very concept of story points. So, this should be avoided by all means.
So, these are the major dos and don'ts of Sprint Planning. If these are kept in mind, it encourages collaboration, and the whole team moves in the same direction. However, if Sprint Planning is not done correctly, it may create confusion and chaos, which will not only demotivate the team but will also affect productivity and cause delays. These dos and don'ts, if adopted correctly, can help the team understand Sprint Planning in the proper perspective and lead them to sustained success.
References
- https://www.scrum.org/resources/blog/5-dos-and-donts-during-Sprint-planning
- https://evolving-digital.com/resources/Sprint-Planning/
