4 Best Ways to Hold Sprint Planning Meetings
Atlassian sets out to provide better software with each passing year. They rely heavily on sprint planning as a crucial part of their agile ceremonies to minimize surprises and refocus their efforts, ultimately resulting in higher-quality code. Let's dive into the four sprint planning principles that have been found to be most effective.
It's important to have a roadmap which outlines the context for two essential agile concepts - epics and versions. This roadmap helps to create a foundation for agile program planning and assists in delivering long-term work. Make sure that your roadmap is always updated, and visible to the entire team, and that epics and versions are accurately listed in Jira before your sprint planning meeting.
Sprint planning involves two fundamental tasks: organizing the backlog and deciding which work will be completed in the upcoming sprint. At Atlassian, we've found that the best way to handle backlog refinement is to conduct a separate meeting with the product owner and scrum master before the actual sprint planning meeting. This pre-meeting is made optional for the entire development team.
What is backlog refinement?
Backlog grooming ensures a healthy backlog accumulation. A healthy backlog: Prioritizes each work item to list the most important work at the top Includes well-formed user stories that the development team can begin implementing Provides an updated estimate for each work item Team Activity: Some teams struggle with estimation. Story points provide a solid framework for estimating work. Include the team in an activity called silent estimation. To start the exercise, place story point values (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) on columns on a whiteboard. Then, ask the team to place story points in the columns they believe are most accurate. Most stories will converge to a single number, and if there's disagreement on the story's point value, it's time to open a discussion on why:
The focus of the sprint planning meeting is to determine and agree upon the sprint goal—the amount of work the team believes it can complete during the sprint. Both the product owner and the development team need to be involved. At Atlassian, we recommend allocating at least one hour for each week of the sprint you plan to cover in the meeting. For example, start with a two-hour sprint planning meeting to cover a two-week sprint. Ideally, schedule sprint planning at the beginning of the week, so the team's context and flow experience less disruption over the weekend
TIP At the beginning of the meeting, the scrum master presents all relevant action items when looking back at the team's history. Then, the product owner provides product or market updates for everyone to be on the same page and have the broader context fresh in their minds.
After the updates, the actual planning meeting begins with the product owner taking charge. To start, the product owner uses the team's average velocity (the amount of work typically completed in a sprint) to compile a "sprint forecast," a proposed set of stories for the sprint that maximizes value for the customer. The product owner should also consider the following three factors: Formal holidays, personal vacations, and team-wide events Priority of news in the backlog (ideally, they suggest the top items) How this body of work will advance the product toward its ultimate goal.
TIP Product owners can use the sprint marker to calculate velocity for forecasting.
If the team is new and does not have a consistent velocity yet, the product owner should refrain from suggesting a sprint forecast. Instead, this should be an all-team exercise as it is crucial to have participation from every member. The team will initially use their best judgment for the estimate and work on a few trial-and-error sprints. Once the team's velocity—nicely visualized with the velocity chart in Jira—is numerically established, use this measure to guide the sprint forecast.
After presenting their ideas for the sprint forecast, the product owner allows the team to validate (and/or adjust) it and agree on an action plan for the sprint.
TIP The team should consider ways to reduce technical debt in each sprint. Creating a quick filter highlighting errors in the team's backlog is an easy way to emphasize significant errors that will be pulled into the sprint while the team continues to work on story points in various areas of the codebase. The "tech debt" quick filter uses the JQL "type in (bug)" feature to limit the view to errors. Extend the JQL query to include additional issue types as needed.
The next step in sprint planning is to go through the stories, articulating what work is required to complete each story. Ensure someone captures the key points for each Jira issue as the team plans. The team should consider the following questions:
Has the definition of the story changed since it was written? Are there new contextual details the team needs to consider?
Is the estimate for the story still valid? Is the entire team in agreement on the estimate? If not, the scrum master should guide the team through a re-estimation.
What tasks are required to complete this story? Use subtasks to help parallelize work and optimize flow. If the team discovers unique stories while solving the work, transform these tasks into fully independent stories.
What are the tester inferences for this story? How can we automate testing?
Is any expert skill set required? How can the team optimize the expert's time without hindering the rest of the team?
How does this story affect the product's architecture? Are there specific individuals the team needs to include in design and code reviews?
Are there any dependencies between stories? Given these dependencies, can we complete all the work during the sprint?
Good planning yields many gains when the sprint starts. The focus here is to understand how work will be done with the scrum master facilitating conversation among the team. Everyone's voice needs to be heard so that when the plan is put into action, the team feels a sense of ownership.
TIP During sprint planning, it's easy to move stories in and out of the sprint when the team is creating the sprint forecast. Simply right-click an issue to move it in or out of the sprint
At this point in the meeting, the team should be satisfied with the sprint forecast. At the end of sprint planning, it's good practice to verbally secure confirmation from everyone in the room about what the team is committing to deliver at the end of the sprint. Additionally, ensure that each team member has at least one task to begin and that no one is copying work.
Team participation and morale will naturally fluctuate from sprint to sprint. These variations typically manifest during sprint planning. Utilize the team's history to understand issues affecting morale. Teams that respond quickly to cultural and development issues are happier, more productive, and write better code.