Tips for an Effective Agile Sprint Planning
Sprints are the core of Scrum, transforming ideas into tangible value. Now it is time to plan the Sprint. Agile Sprint Planning comes at the end of a Sprint, but the end of a Sprint can be tiring for a team. Between the rush to finish off user stories, Sprint Review, and the Sprint Retrospective, Agile team members will be tired. Your team will need a Sprint Planning that is effective as possible.
So what can you do to enhance the effectiveness of your Agile Sprint Planning? Here are some tips.
What is an Agile Sprint Planning?
Before we get started, let’s have a refresher of what is a Sprint Planning.
According to the Scrum Guide, the Agile Sprint Planning is described as:
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
The Scrum Guide also states that Sprint Planning address the following topics:
Why is this Sprint valuable?
What can be Done this Sprint?
How will the chosen work get done?
Quickly Discuss Valuable Agile Metrics
Valuable Agile Metrics provide so much information for an agile team. Benefits of quickly discussing key agile metrics at the start of Agile Sprint Planning will help the agile team measure experiments, provide confident planning, and increase overall output quality. Take advantage of this quality information.
Which valuable agile metrics are worth discussing? The following are beneficial for Agile Sprint Planning:
Average Velocity: The Average Velocity is the average amount of story points the agile team is completing over multiple Sprints. Average Velocity will help Sprint Planning by providing a number of Story Points an agile team should aim to plan, backed by historical data.
Velocity Variance: Velocity Variance shows the percentage difference what the last sprint’s velocity was compared to the team’s average velocity. Going hand in hand with Average Velocity, Velocity Variance will provide a level of confidence when planning based off Average Velocity.
Committed vs. Completed: The Committed vs. Completed ratio is the number of story points that were committed to at the beginning of the sprint vs. the number of the story points that were committed to at the beginning of the sprint that were completed. Bring this valuable agile metric only if you are noticing a trend of the agile team over or under committing the last 2–4 Sprints. Remind the agile team that stability will help with predictability.
Automated Test Coverage: This valuable agile metric is the ratio of number of automated user test to the number of functions/modules in the codebase. Mentioning the Automated Test Coverage will assist the team in understanding if they need to plan some time in the Sprint to improve test coverage.
Determine Upcoming Sprint Capacity
Sprint by Sprint, the amount of capacity changes. Agile team members have vacations, personal time off, there may be workshops, or a there is a holiday. When you get into the details of Sprint Planning, it is not only handy having valuable agile metrics, but also the Sprint Capacity of the Agile team.
After you discuss the valuable agile metrics, and before you get into the detailed Sprint Planning, ask the team members who has time off and for how long they are away. Refresh the team on any upcoming holidays, or workshops. The agile team will now be able to take the Sprint Capacity into consideration.
Using a shared calendar is a great way to support understanding upcoming Sprint Capacity. Ask team members to put their known time off in the calendar as soon as they know when they will be taking time off. A shared calendar is another beneficial tool for an agile team, as it enables members to see if someone is absent on any given day.
Remind Team of Retrospective Action Items
An effective Retrospective will produce important action items for your team. Whether it be a task for some team members to do, or to try a new process, these action items take work which you will have to plan into your Sprint. Remind the agile team about the upcoming action items.
Adding the action items as user stories will help keep them visible. Before picking stories to work on, add these action items to the top of the upcoming Sprint. Having them front and central while you plan will ensure the agile team does not forget about them.
Once the agile team sees the visible action items, the team will be able to plan around the action items. Team members will be able to highlight user stories that the action item can work together with. The team could see a process improvement and adjust the commitment knowing their may be some growing pain with the new action item. Action items involve work, so plan the work into the Sprint.
Address Stories that Carried Over
User stories carry over. It happens. For some mature teams, maybe it doesn’t happen every Sprint, but it happens. The unknown can come up, or a story could of been just too big. You will have to make a plan how to handle the carry over stories.
Addressing the user stories that do carry over is needed. Ask the team how much effort is remaining. Don’t resize the story, but write down the remaining story size and use it in your calculation when planning around your average velocity and other valuable agile metrics.
The product may be pivoting too. Higher priority user stories may have came up. Moving the user story into the Product Backlog might be necessary. Unfinished work may not be the top priority anymore. When you do move a user story back into the Product Backlog, ensure the user story has notes on where the code lives, where the developer left off, and any other important information that may not be in the user story.
Ensure each User Story meets the Definition of Ready
The Sprint is going well. User stories are being finished, unplanned work is being handled well. It looks like the Sprint goal will be achieved. All of a sudden, the next user story to be worked on looks like this.
We need to fix the report. It is showing the wrong data.
What report? What data? Who is reporting the error? Now the Sprint is at risk. This user story did not meet the Definition of Ready and time have to be spent refining the user story after Sprint Planning.
A mature agile team uses a Definition of Ready. A Definition of Ready is a checklist of items that need to be done before a developer should start to work on a user story. Items may include UX designs included, story has been sized, know dependencies are listed etc.
During Sprint Planning, ensure every user story you add to the Sprint matches the Definition of Ready. Ensuring this will reduce risk and lead to better predictability. If you see a trend of user stories not matching the Definition of Ready during Sprint Planning, this may be due to a poor backlog refinement. You may have to refine the user story in Agile Sprint Planning if it is needed in the upcoming Sprint, but if the user story is a nice to have, push back and exclude it from the upcoming Sprint till it can go through a proper refinement.
Do Not Combine Product Backlog Refinement and Sprint Planning
One of the main complaints of Agile is “there are too many meetings”. Many think a simple solution would be just to cancel the ceremony and combine it with another. Sprint Planning and Product Backlog Refinement both revolve around user stories, so an immature agile team will combine them. In most cases, the root of the “too many meetings” issue is actually that the ceremonies are not effective at getting to the ideal outcome.
Address the root issue instead of combing. Find out why agile team members may feel “there are too many meetings”. The Product Backlog Refinement and the other agile ceremonies may not be effective at achieving their ideal outcome. The backlog health may be poor. Agile team members may be in meetings that they are not needed in or provide any value to them. All potential issues that can be addressed to help reduce meeting overload. Agile leaders can work together to address all of these issues.
Combining Product Backlog Refinement and Agile Sprint Planning will lead to more issues, and less time to develop. Sprint Planning will be longer, leading to meeting burnout. When it comes to the Sprint Planning session, team members will not be focused to plan a strong Sprint. The agile team will not have the proper time to refine a user story. User stories will have missing or poor information. User stories with outstanding questions needed answered for it to meet the Definition of Ready will be missed. These issues and more, which just lead to poor output, and more time spent gathering requirements mid-sprint.
Keep Conversations Focused
Agile Sprint Planning frequently derails at this stage. As the team reviews each user story for inclusion in the upcoming Sprint, they may begin to devise solutions for the story immediately. Instead of a quick high level confirmation that the story meets the Definition of Ready, the team starts to get into the finer details and tries to plan the story itself.
Do not be afraid to step in. Ensure that the conversation stays high level. Allow for some discussion, but once you see it going deeper into the details of the story, you will have to step in. Remind the team, that the ideal output of Sprint Planning is to start the next Sprint. Ask the team to discuss the finer details after.
If conversations about user stories continue to go deep into the details, this could be a sign of different issues. User stories could be missing information, product backlog refinement is poor, or simply the team has a trend of going off topic. When you see the pattern continue, ask the team if the story is truly ready for development. Ask if they have all the information. Ensure you bring the issue up at Retrospective. Keeping a close eye at refinement for best practices will help fix this issue.
Plan “Slack” within the Sprint
Everyday in your life, unplanned things happen. You may have a general idea of what you are doing that day, but something unplanned comes up. You adjust, and move on with your day. The same should happen for Agile teams.
But how do you handle these unplanned events? If you knew what they were before Sprint Planning, you would of added them to the Sprint Backlog. Adding “Slack” to a Sprint gives a team that flexibility when the unplanned comes up.
By planning 80% of your Sprint, you leave a 20% cushion. Some issues that can de-rail a Sprint are, production bugs, team members being sick, or the stories being more complexed than originally though. Giving this 20% will ensure the Agile team has space to handle these unknowns without rushing through the Sprint Backlog.
The Sprint going well, and no unplanned work come up? Great, now you have 20% open for learning, working on small low priority bugs, or getting a head start on upcoming work.
Order User Story Priority in Sprint Backlog
Agile focuses on delivering the most important items to the customer first. With an MVP focus, the bare minimum is prioritized in a roadmap, and then the Product Backlog. The Product Backlog is then worked on in order. Using this idea, the Sprint Backlog should be prioritized too.
In each Sprint, certain items will be assigned a higher priority than others. Having the Sprint Backlog order by priority provides many benefits. Team members will know what to work on next if they complete a story, leadership will easily be able to see the main goal of the Sprint, and the Agile team will know what user stories to focus on completing first.
At the mid-sprint check in, and near the end of the Sprint, if the highest priority items are not being completed and at risk at carrying over into the next Sprint, it will be visible to the entire Agile team. The Agile team can then decide if they should stop working on some of the lower priority user stories, and help swarm on the higher priority items.
Confirm with Team Sprint Goal is Achievable
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
Planning a Sprint is not just decided by the Product Owner. Each role has influence when planning a Sprint. Product Owner will present what are the priority stories and ideal goal. The Scrum Master provides valuable agile metrics to help the team plan. The Technical Lead will suggest technical debt that can be addressed. And the developers will provide feedback of what can be done.
As a team goes through each user story, adding them to a Sprint, it will be hard to take a step back and look at the whole Sprint. Developers may initially overcommit or Product Owners ask the team to do too little. Taking a step back and looking at the entire Sprint Backlog will help.
Keep an eye on the story point commitment. When an Agile team looks at a Sprint, they may see red flags. Multiple large stories may be in the Sprint, dependant stories may be in the Sprint, or some of the user stories don’t align with the Sprint goal. The valuable agile metrics provided above will give you a clear understanding of what an achievable target should resemble.
Ask the team how the Sprint looks. Is it achievable? Are the red flags that was noticed addressed? Is the Sprint Backlog ordered by priority? and are the priority stories achievable without risk early in the Sprint? Asking these questions at the end of planning will ensure confidence going into the next Sprint.
Conclusion
Implementing these tips will maximize the benefits of your Agile Sprint Planning. Sprint Planning sets out the work for the upcoming Sprint and marks the first ceremony of the Sprint cycle. By following these tips for effective Agile Sprint Planning, you can guarantee a robust plan is ready for action.
Share in the comments what tips that work for you and your team to improve this important Agile ceremony.
Find these tips helpful? Check out my tips for other Agile ceremonies:
Tips for an Effective Daily Scrum Stand-up
Tips for an Effective Agile Sprint Retrospective
Tips for an Effective Agile Product Backlog Refinement
Tips for an Effective Agile Sprint Review
👏 If you have enjoyed reading my article, remember to comment, clap, and highlight. It will encourage me to write more content.
