4 best practices for sprint planning meetings - Work Life by Atlassian (2024)

Every new year brings a renewed sense of purpose and in the software world, promises to ship better software. At Atlassian, we rely heavily on the agile ceremony of sprint planning to refocus execution, minimize surprises, and guarantee overall higher quality code during the new year.

1. Check your roadmaps before you meet

Time passes faster than we think. So it’s a good idea to reviewyour project’s roadmap during thefirst two weeks of the new year. The roadmap sets the context fortwo important agile concepts: epicsandversions, whichprovide the backbone for agile program planning and help track delivery of longer-term work. Make surethe roadmap is current, visible tothe whole team, and that epics and versions are correctly listed inside of Jira before your sprint planning meeting.

2. Hold a meeting before the meeting

Sprint planning involves two key tasks: grooming thebacklogand deciding which work to complete in the upcoming sprint. At Atlassian, we’ve found that backlog grooming is best done in a separate meeting with the product owner and scrum master before the actual sprint planning meeting. We make this pre-meeting optional for the full development team.

What is backlog grooming?

Backlog grooming ensures that the backlog is healthy. What does that look like? Glad you asked. A healthy backlog:

• Prioritizes each work item, with the most important work listed at the top
• Includes fully-formed user stories the development team can begin to execute on
• Contains an up-to-date estimate for each work item

Teams at Atlassian hold short backlog grooming meetings a couple days before sprint planning. Plan on spending 30 minutes in this meeting to triage the issues you’re most likely to take on in the next two sprints. Sometimes you’ll find items that don’t have enough detail to be executed on or need more contextual information from the product owner. That’s the beauty of grooming the backlog in advance. Those gaps can be filled in between meetings so they aren’t blockers (or time-wasters) during the actual sprint planning. Thus, grooming the backlog before hand gives the team more time during sprint planning to consider their options for the sprint and ear-mark items for the next sprint, as needed.

Team Activity: Some teams struggle with estimation. Story points provide a sound framework for estimating work. Engage the team in an activity calledsilent estimation. To start the exercise, place the story point values (0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) in columns on a white board. Then ask the team to place the user stories in the column they think is most accurate. Most of the stories will gravitate to one number, and if there is disagreement on the story point value it’s time to open a discussion as to why.

Tip: Check out our guide to project management, perfect for agile teams. Even non-project managers can deliver the goods without losing their minds.

3. Inform sprint planning with data

The focus of the sprint planning meeting is to set and agree upon the sprint goal–the amount of work the team believes it can complete during the sprint.The product owner, scrum master, and the full development team all need to be in attendance. At Atlassian, we recommend a minimum of one hour for each week of the sprint that you plan to cover in the meeting. For example, start with a two-hour sprint planning meeting to cover a two-week sprint.Ideally, schedulesprint planning early in the week. Then the team’s context and flow is disrupted less by the weekend.

At the start of the meeting, the scrum master presentsany relevant action items from the team’s retrospective. Next, the product owner giveproduct or market updates so everyone ison the same page and has the broader context fresh in their minds.

After the debriefs, it’s the product owner’s responsibility to start the actualplanning conversation. To get started, the product owner uses the team’s averagevelocity (the amount of work typically completed in a sprint) to compile a suggestedset of stories for the sprint, called the “sprint forecast”, that maximizes value to the customer. The product owner should also consider thesethree factors:

• Public holidays, personal vacation, and team-wide events
• Priority of stories in the backlog (ideally, they suggest the top-ranked items)
• How (and whether) that body of work will get the product closer to its final goal

If the team is new and doesn’t have an established velocity, the product owner shouldn’t suggest a sprint forecast. Instead, this should be an all-team exercise because it’s important to have buy-in from each member. At first, the team will use its best judgment with regard to the forecast, and work through a few sprints of trial and error.Once the team’s velocity–nicely visualized by the velocity chart in Jira– is established numerically, use that metric to guidethe sprint forecast.

Once the product owner presents their ideasfor the sprint forecast, the team can validate (and/or adjust) it and agree to a plan of action for the sprint.

The next step in sprint planning is to walk through the stories and describe what work is required to complete each story.As the team plans, make sure someone is capturing the key points inside each Jira ticket.That way both the decision and the rationale are easy to see later. The team should consider questions like…

• Has the story’s definition changed since it was written? Is there new contextualinformationthe team needs to consider?
• Is the story’s estimate still valid? Does the entire team agree on the estimate? If not, the scrum master should guidethe team through re-estimation.
• What tasks are required to complete this story? Usesub-tasksto help parallelize work and optimize flow. If the team finds unique stories as they break down work, promote those tasks to fully independent stories.
• What are the testing implications for this story? How can we automate testing? (Remember that manual test scripts are essentially technical debt.)
• Are any specialist skill sets required? How can we optimize the specialist’s time without blocking the rest of the team?
• How does this story affect the product’s architecture? Are there specific people the team needs to involve in design and code review?
• Are there any dependencies between stories? Can we complete all of the work during the sprint given those dependencies?

There’s a strong temptation to rush through this detailed exercise. Butgood planning pays numerous dividends once the sprint starts. The focus here is to understandhowthe work is going to get done, with the scrum master facilitating conversationamongstthe team. It’s important that everyone isheard so the team feels a sense of ownership once the plan is in place.

4. Ready, set, sprint!

At this point in the meeting, the team should be comfortable with the sprint forecast.At the end of sprint planning it’s good practice to get verbal approval from everyone in the room about what the team is actually committing to shipping at the end of the sprint.Also, establish that each team memberhas at least one task to start on and nobody is duplicating work.

Team engagement and morale will naturally fluctuate from sprint to sprint. These variations often show up during sprint planning, but resist the temptation to dig into it right then and there. Instead, use the team’s retrospective to understand any issues that are impacting morale. Teams that respond quickly to culture and development concerns are happier, more productive, and write better code.

Hungry for more? Check out The Agile Coach – a site witharticles, webinars, and ebooks on all things agile.