Sprint planning basics set you up for success

[Antonia V.]

[Click To Tweet]

What I’ve learned from working on a scrum team is that the most successful sprint planning happens when there are distractions that prevent the team from focusing on the task at hand are kept to a minimum.

One way to achieve this is for the Product Owner (PO) and Scrum Master (SM) to work together to groom the backlog before the rest of the team joins them to plan the sprint. This helps keep the sprint planning meeting that follows on track, because the PO and SM can decide preemptively which work is the more important to the project and put this work at the top of the backlog. Work that is less relevant can be placed at the bottom of the backlog, which keeps it from being focused on by the team during the planning session. What I’ve found is that if this is accomplished before a sprint planning meeting, less time will be lost during the meeting debating as a larger group on which work is relevant.

Another good tip is to include a quick description of the sprint planning agenda, along with links to the user stories that are being considered for the upcoming sprint, in the meeting invitation. This way the dev team can have some context and will have time to think about how the upcoming sprint might go and any relevant information they might want to bring up in the meeting before the meeting itself.

During the sprint planning meeting, I’ve found that a good rule of thumb is to set aside at least an hour at the beginning of the week (or 2 hours for a 2 week sprint). This ensures that the team has enough time to figure out what needs to be done and plan carefully. I’ve found that sprint planning meetings that happen early on in the week are more effective, as that way the goals of the sprint remain fresh in the teams’ minds throughout the first week of the sprint, and the work flow isn’t disrupted as much by thoughts of weekend adventures.

My final tip is to keep sprint planning time separate from other things such as retrospectives. It’s easy to get distracted talking about what happened in the last sprint and not have enough time or focus to talk about the upcoming sprint.

Happy planning!

[amer]

We follow all of these techniques and it works well for us. One more thing we do (which I'm curious if you think is good or bad) is that the PO and SM also do rough estimates in their backlog-grooming session to get a little past the velocity (so when we send the agenda out, we can define that we're looking at these issues - sometimes we just set the sprint up without starting it as a prerequisite to the meeting). Of course the team has the option to debate and adjust times, but it helps box in huge backlogs.

[Antonia V.]

That's a good question. I think it partly depends on your team's dynamic, as you want to avoid creating an "us vs. them" mentality between the dev team and PO/SM. The PO should prioritize the work in the sprint meeting, but the team should select how much work they can do for each sprint. I don't think I would go so far as to have the PO/SM set up a sprint before the meeting, as it somewhat infringes on the concept of the self-running team. I would also make sure that in sprint planning meetings the development team's time estimates are always taken seriously and acted upon, along with their thoughts on how much work they think they can accomplish during the sprint. At the end of the day, they are the ones doing the work and it can be difficult to make those estimate from an outside perspective.