Having an efficient sprint planning meeting agenda goes a long way in advancing a software product. Agile software development aims to add more value to a software product through incremental development. We call these increments sprints.
A sprint represents a specific amount of work that can be completed in a given amount of time. The sprint planning meeting aims to allow the development team to identify, estimate, and include meaningful work in an upcoming sprint. In this post, we’ll be exploring the basic building blocks of a sprint planning meeting agenda.
What Is the Sprint Planning Meeting?
As I mentioned before, a software development sprint represents a grouping of user stories that the development team has committed to completing during the next iteration of the development process. However, before each development sprint can start, the development team must understand the work and commit to completing it in the time allocated for the sprint.
The sprint planning meeting is a formal meeting during which the development team identifies and estimates the work for the next sprint.
It’s this understanding of the work and the commitment to complete it that requires a specific kind of meeting to occur.
Let’s start by looking at the main goals of the sprint planning meeting.
The Goal of the Sprint Planning Meeting
How do you know this meeting is a success? Or, even better, when should the sprint planning meeting be considered done?
The ultimate goal of the sprint planning meeting is for the development team to commit to completing a significant chunk of work during the coming sprint.
Essentially, choosing work for a sprint involves understanding and estimating the work. In order to achieve this ultimate goal, there are two supporting intermediary goals that also have to happen during this meeting.
Firstly, the product owner gives a vision or justification for the work considered for the next sprint. The product owner identifies and prioritizes what represents meaningful work and why it’s meaningful. Consequently, the development team evaluates and actually picks the work for the upcoming sprint.
Let’s now focus on who’s attending this meeting and develop a sprint planning meeting agenda.
Who’s Coming to the Sprint Planning Meeting?
Everyone attends the sprint planning meeting. OK, not the entire company, but the entire development team must attend. This includes the product owner, scrum master, developers, and quality engineers. Let’s look at each of these people and their specific roles to play during the sprint planning meeting.
The Product Owner
What does the product owner need for this specific meeting?
The product owner creates and maintains the product vision, which is usually based on customer input, market research, and company requirements. The product owner keeps the big picture in mind and articulates it frequently to the rest of the team. In addition, the product owner ensures that every user story in the backlog aligns with the product vision.
Therefore, in preparation for the sprint planning meeting, the product owner has already assigned clear priorities to the user stories in the backlog. Having clear priorities aligned with customers’ needs ensures that development efforts focus on the most meaningful work.
At the beginning of the sprint planning meeting, the product owner reiterates the product vision and how this coming sprint aligns with the product vision.
The product owner will be successful when the development team has understood the product’s vision and how the coming sprint advances this vision.
The Scrum Master
If the team has a separate scrum master role, this person will be ready for the sprint planning meeting with two things: a good understanding of current team velocity and a good understanding of upcoming work schedule restrictions.
Understanding team velocity goes beyond just knowing the number of points the team usually accomplishes during a sprint. It also includes understanding the normal circumstances with the normal team velocity. Risk and variations to normal team velocity include things like changes to the development team changes, technology, or company. The scrum master keeps these things in mind and brings them forth.
Secondly, the scrum master brings forth any time limitations for the upcoming sprint, like vacations and holidays.
The scrum master will be successful when the development team has understood the limitations for the coming sprint.
The Development Team
Everyone involved with doing the work attends this meeting. A development team may contain designers, user experience experts, quality assurance, and developers, of course. Larger companies can have different roles shared between different development teams. However, for this post, we only consider the simpler case when we have one development team dedicated to one product.
How do members of a development team prepare for the sprint planning meeting? Well, it all depends on company culture.
Some companies purposely don’t want developers to prepare for this meeting so they can look at the user stories with fresh eyes and without prejudice. Other companies require preparation. These companies expect developers to read through user story descriptions and give some thought to the implementation.
The development team is successful when they have clearly understood, evaluated, and embraced the work for the upcoming sprint.
With all these things in mind, let’s put together a sprint planning meeting agenda.
The Sprint Planning Meeting Agenda
Here are the main building blocks for your sprint planning meeting agenda. It’s important to mention that these specific events usually blend together into one free-flowing conversation instead of a specific set of steps.
1. Maintain Product Vision
The product owner presents the context for the work considered for the next sprint. The product owner explains where the user stories come from, such as customer requests, customer support, or the marketing department.
In addition, some user stories come from older sprints because they were not completed previously. Lastly, a sprint may also include important bugs. Bringing all of these things together helps form a specific sprint goal.
2. Consider Existing Constraints
The scrum master presents any limitations for the upcoming sprint as well as existing team velocity. Limitations include upcoming holidays and staff vacations. Team velocity helps the team evaluate (velocity should only be used by the team) what they can realistically complete during the coming sprint.
3. Estimate the Work
The development team reads through each piece of work (i.e., user story) and evaluates its complexity. This is notoriously difficult, which is why increasingly teams are turning to tools like LinearB to plan more accurately. For agile development, we estimate complexity, not time required to complete. As a consequence, we assign complexity points to each story we evaluate.
Evaluating upcoming work means that each team member gives their estimation for a user story based on the information presented and each member’s experience. Regardless of the voting mechanism used, the goal is to achieve a team consensus where team members are comfortable with the complexity score assigned to each story.
Estimating the work for an upcoming sprint must be a free-flowing conversation.
4. Commit to the Work
Toward the end of the meeting, the team commits to work for the upcoming sprint. Some teams make this a formal event, while others keep it as informal as saying, “Let’s get it done!” It’s worth repeating that the development team picks what they’ll work on during the next sprint. It’s not the product owner or the scrum master who ultimately chooses.
The team performing the work determines and commits to the work to be completed.
Do You Have a Sprint Planning Meeting Agenda?
In this post, we explored the basic building blocks for an efficient sprint planning meeting agenda. In addition, we considered what happens during the sprint planning meeting. Having a successful sprint planning meeting is crucial to completing meaningful work and developing your product.
For more tips on how to best plan for a sprint, check out this post.
