The Scrum methodology is at the heart of the Agile framework. The self-organizing teams of Scrum epitomize how the collective wisdom of a team can be more beneficial than the experience of an individual. To understand how the self-organizing teams of Scrum work, read my colleague Shesha Rajkumar’s blog here.
Today, however, we will be talking about another aspect of the Scrum methodology – Sprint Planning in Scrum Ceremonies
Scrum Ceremonies are meetings with pre-defined parameters in respect to goals, the number of participants, and even the time taken to complete the sprints. The Scrum Framework utilizes the following 5 key Ceremonies and inspects & adopts each of them:
- Sprint Planning
- Daily Scrum/Stand Up
- Sprint Review
- Sprint Retrospective
- Product Backlog Refinement/Product Backlog Grooming
What is Sprint Planning?
The goal of Sprint Planning is to create the Sprint Backlog & set the Sprint Goal
The prerequisite for Sprint Planning is a refined product backlog which is reviewed along with the Product Owner (PO). The PO and the Scrum Team collaborate to pick high value items stacked at the top of the backlog. Here, the estimated time, along with the ‘Definition of Ready’ and ‘Acceptance Criteria’ are captured.
The Scrum Team is expected to start on the first day of the sprint. The duration of sprints can vary between 4hrs for the 2-weeks sprint and 8hrs for the 4-weeks sprint.
The main intention of the Sprint Planning is to arrive at a clearly defined Sprint Goal with the commitment from the team to complete it within the stipulated time agreed.
Challenges faced during Sprint Planning
Usually, Sprint planning is a lengthy meeting. It can get quite challenging to keep the team focused throughout the planning. I usually have small 5-10 mins breaks in between so the team can refresh and come back focused for the rest of the planning.
Most often, challenges faced during Sprint Planning is what we call the ‘scope creep’ where there will be a request from the team to add a new feature, function, or requirement beyond the agreed scope. In this situation, we can negotiate with the PO to prioritize the must have’s in the current sprint and move the rest to the backlog.
There are also times where Interdependent user stories are not identified during the sprint planning. This is an important aspect where we try to make sure the user story is not put on hold during the sprint. The development team, therefore, needs to clearly identify and call out the interdependent user stories.
The Do’s of Sprint Planning
In my experience, there are a few best practices we can adopt during Sprint Planning.
First and foremost, pick at least 1 retrospective improvement to implement in the current sprint, and track progress to closure. This, of course, is not mandated and should be worked on in collaboration with the PO and the Scrum team. However, it is worth looking into any one of the retrospective improvements from the previous sprint for a better outcome in the current sprint.
Secondly, check for the team’s capacity and velocity. It is always advisable to calculate the team’s capacity, consider the holiday calendar & team vacation plan, and also the velocity prior to the sprint planning to ensure the sprint is completed within the estimated time, even in the case of limited availability of the team members. This also helps in raising an alarm if the goal is not met in between the sprint due to unforeseen delays which could be due to various factors.
Next, keep the sprint goal-specific rather than having an abstract goal. Make sure the Sprint Goals are articulated as much in detail as possible. For example;
- Build an application for the Play Store
- Search to display all the top 50 products
- Autocomplete search when you type 3 letters of the product
As opposed to abstract goals, which can be quite ambiguous, such as;
- Create an application
- Search products
- Auto-populate the search
Lastly, try to optimize the bigger ‘User Stories’, which can be more than 8 or 13 story points; by breaking them into multiple ‘User Stories’ to accommodate them in the Sprint.
The goal of Sprint Planning is to ensure there is a minimum viable product delivered at the end of the Sprint.
The Don’ts of Sprint Planning
Developers should not try to accommodate too many ‘User Stories’ at the same time in addition to bugs and new changes in a single sprint. However, the priority of the bugs and stories is defined by the PO.
The Scrum Master should not ignore the team’s velocity as calculated from the previous sprint. Having a clear understanding of velocity helps in identifying the timing risks and highlighting them to the PO during planning.
Avoid inviting too many external stakeholders to the sprint planning meeting which can lead to unnecessary confusion and extend the Sprint Planning meeting.
The team should avoid spending too much time discussing any ‘User Story’ which has less information. This should be dealt with separately in ‘Product Backlog Refinement’ sessions in the interest of time during the sprint planning.
Role of a Scrum Master during Sprint Planning
It is easy to learn scrum but difficult to master it. A Scrum Master needs to be a good coach for the team. He/She needs to guide the team to follow the scrum values.
During Sprint Planning, the Scrum Master needs to ensure the team does not get distracted and remain focused on the planning as it is a crucial activity. He/She also needs to make sure the planning does not get extended or rescheduled for another day. The Scrum Master also needs to encourage the team to probe more on the requirement and have adequate details captured and ensure the ‘Definition of Ready’ is met.
The team being both transparent and honest about their estimation of the User Story to ensure the Sprint Goal is achieved by end of the Sprint should help the outcome to be what everyone expects and on time.
