Getting the Sprint Planning Done Right

Simplifying how you plan your Sprints.

Depending on how you handle your Sprint Plannings, it can be a blessing or a curse. The Scrum team may leave the room empowered or trapped, motivated or demotivated, inspired or pressured. 

What’s your experience with Sprint Planning? Have you ever stumbled upon any of the following?

• Every Sprint is the same, more features, more output, and no clear goal
• Product Owners pressure the team to commit to output and forget the why
• Scrum Masters focus on velocity increasing and don’t challenge Product Owners or Developers
• Developers despise planning because they believe it gets in the way of getting their job done

If any of the above speaks to you, welcome to the club. You’re not alone.

Many teams struggle with Sprint Planning, and as a result, Sprints become a trap and don’t help teams unleash their best. 

Let me help you understand the critical aspects of valuable Sprint planning.

Understanding Sprint Planning

Many misunderstandings surround Sprint Planning, and that traps teams. Let’s take a minute or two to clarify what this critical event is all about.

I like to start with the end in mind. An excellent Sprint Planning will result in the following:

• Clarity on why the Sprint is important
• Commitment to reaching a goal
• Flexibility on how to work during the Sprint
• Motivation to reach the goal

The above is what you get when you succeed with Sprint Planning, and the following is what you get if you fail with it:

• A list of features to deliver unrelated to a goal
• No commitment to any goal
• Confusion on what matters most
• Unclarity on why the Sprint matters
• Pressure to deliver more and lack of space for creativity

Now let me help you understand how you avoid that and how you get meaningful results.

Before the Sprint Planning

You’ve got little chance to succeed with Sprint Planning if you miss something that needs to happen before the session.

Sprint Planning isn’t the moment to do everything from refining work, prioritizing, and agreeing on a goal to evaluating how to reach it. That would be exhaustive and counterproductive, but it’s often the case.

Suppose your Sprint Plannings take place every other Monday. Here are the things that need to happen before it:

• Refinement: Ideally, 3 to 4 days before the Sprint Planning, the Scrum team refines the relevant backlog items for the upcoming Sprint.
• Order the Product Backlog: The Product Owner should sort the Product Backlog items according to their priority after the refinement.
• Draft the Sprint Goal: The Product Owner reflects on what matters most now and drafts a Sprint Goal to present to the team.
• Review availability: The Scrum Master clarifies the team members’ availability for the upcoming Sprint. This helps decide on the commitment the team can make
• Review the Sprint result: The Product Owner reviews the current Sprint result and decides what to do with sprint carry-over and potential feedback from stakeholders.

Once the above steps occur, you have a better chance of having a valuable Sprint Planning session.

During the Sprint Planning

With the proper preparation, the session should go smoothly. I generally follow more or less the following sprint planning agenda:

• Set the stage (5 min): The Product Owner reflects on the previous Sprint by talking about the goal, then sets the stage for the next Sprint. The current Sprint is closed, and the team is ready to start a new one.
• Why it matters (5 min): The Product Owner elaborates on why the Sprint matters and what would make it successful, then presents the Sprint Goal.
• Sharpen the Sprint Goal (10 min): The whole Scrum team reflects on their capacity for the Sprint and shapes the Sprint Goal to fit its capacity and expected results. It’s fundamental to set a goal and not a task. For example, “Customers can refund their orders without talking to anyone.”
• Select the PBIs (20 min): Based on the Sprint Goal, Developers select the PBIs related to it and align with the Product Owner. Note that this is the initial part and not a commitment to tasks. The team may adapt as necessary during the Sprint.
• Align on the how (90–120 min): Now is the moment to discuss how the team will self-organize to reach the Sprint Goal. This may take between 1.5 to 2 hours depending on the team size and experience. At this moment, the Product Owner may leave the room and remain available if the team has contextual questions.
• Start the Sprint: As the team concludes the alignment on how they can start the Sprint and rock it.

After the Sprint Planning

Most teams I know would stop there and wouldn’t do anything else. However, I’d encourage taking some additional steps to ensure clarity. As the saying goes, you cannot over communicate.

Here are some ideas:

• Make the Sprint Goal visible: Nowadays, we mainly work remotely, but if you can, put the Sprint Goal on the wall in front of you so that nobody forgets it. The Sprint Goal should be present every single day of the Sprint. If you work remotely, create a beautiful image with it and share it as the first thing of your Daily Stand-up. This would be the Scrum Master’s job.
• Inform your stakeholders: Don’t keep your stakeholders in the dark—drop a message to them with your Sprint Goal and why that matters now. You may give an overview of activities related to reaching the Sprint Goal, but make sure the objective is reaching the goal and not delivering a list of tasks. This would be the Product Owner’s job.
• Adapt the Product Backlog: As you start a new Sprint, don’t forget to curate your Product Backlog. This is a live artifact that should remain beautiful and shiny. That’s another one of the Product Owner’s jobs.
• Get things moving: Developers are self-managing, and as they start the Sprint, they should quickly align on how they organize themselves to get moving towards the Sprint Goal.

Final Thoughts

Knowing that many Scrum teams miss the mark during Sprint Planning hurts me. I know that because I’ve led several teams to endless traps. 

Sprint Planning done wrong will transform your Scrum into a Waterscrumfall.

The Sprint Planning done right will empower your team to bring their best to work daily.

I know that stakeholders push teams in several directions. Don’t do as I did at the beginning of my career. Any of the following will trap you:

• Divide and conquer: Prioritize your Sprint by capacity and assign tasks to team members instead of giving them a valuable Sprint Goal
• Meaningless or nonexistent Sprint Goal: Without a goal, the team has no reason to collaborate. A pointless goal will lead to the same result. Be careful with goals like “Finish 80% of the prioritized tasks” or “Onboard a new developer into our team.” A valuable goal makes clear the direction the team should go and empowers them to be creative
• Everything at a single event: The Sprint Planning should be precise. Set the goal, clarify the why, and define how to get there. If you’ve prepared enough, you’ll end up with an exhausting and confusing session. Do your homework

“Plans are worthless but planning is everything”  — U.S. President Dwight D. Eisenhower