Which One Is True for Sprint Planning

October 02, 2024

7 min read

Sprint Planning is like preparing a Thanksgiving shopping list. Without a plan, expect last-minute scrambles and chaos. Plan now, and execute smoothly later.

Which One Is True for Sprint Planning?

The statement “The work to be performed in the Sprint is planned” is true for Sprint Planning. But what makes the other options incorrect?

Which one is true for Sprint Planning?
A.) The work to be performed in the Sprint is planned
B.) A demo of the previous increment is done
C.) Customers will share the feedback
D.) The Product Backlog is refined

Knowing the correct answer won’t cut it for those multiple-choice questions. You have to dig deeper. Why were the other options even included? What traps are they trying to set? Understanding why each choice is wrong takes you from just getting by to internalizing it. Curious? You should be—it’s where the real learning happens.

B.) A Demo of the Previous Increment Is Done

At first glance, this option could work, though answer A felt like a better fit. This answer falls short for two reasons. First, “demo” isn’t an official term in Scrum. It appears exactly zero times in the Scrum Guide. While a Sprint Review can include a demo, it’s not the main focus, despite what many think.

Second, connecting the timing of a demo to Sprint Planning feels like a stretch—whether the Sprint Review has already happened or not is, at most, a weak link to Sprint Planning.

This one leans more towards a Sprint Review than Sprint Planning. Customers typically don’t attend Sprint Planning sessions, and it’s not meant to gather feedback. Its purpose is to plan, not to please. So, trying to connect it here doesn’t hold up.

D.) The Product Backlog Is Refined

At first, I read this as if the Product Backlog should already be refined before Sprint Planning—and yes, that’s true. But that’s not what this answer actually says. It simply states the backlog is refined, implying during Sprint Planning, which isn’t quite right. Sure, some updates might happen, but it’s not the event’s primary focus. My overactive brain just added context that wasn’t there.

Understanding why each option is off-base opens up a bigger question: what’s the real purpose of Sprint Planning?

What Is the Purpose of Sprint Planning?

Sprint Planning defines a plan for the Sprint by setting the Sprint Goal (why), selecting Sprint Backlog items (what), and adding details to prioritize tasks (how). Teams often focus on what to build but miss the why and how resulting in misaligned goals and overextension.

Anyone following Scrum for a while will likely have the “what” part down. At the very least, you’re using some method to figure out how many Product Backlog Items you can realistically handle and then pulling in just enough to meet that limit.

You might even hold a second session to map out implementation details (the how). Whether adding bullet points to existing cards or breaking stories into tasks, it’s good to at least give the stories a once-over to ensure they’re right-sized. Teams also utilizing Kanban sometimes do this by checking for any reason they can’t complete a work item within the typical service level expectation.

The Sprint Goal (the why) is where I see many teams trip up. You might say, “Not us, we always have a goal—complete all the stories in the Sprint Backlog!” I hate to break it to you, but that’s not a real goal. Who cares if you complete all the stories? What does it achieve? A solid Sprint Goal should represent value and be something you’d be proud to share in a company newsletter. It should also help guide and prioritize your work throughout the Sprint.

A hand checking off items on a checklist, Caption:Completing everything doesn’t matter if it accomplishes nothing.

Imagine you’re cooking Thanksgiving dinner and suddenly realize you don’t have enough eggs to finish all your dishes. The stuffing and two desserts still need eggs—so which do you prioritize or abandon? If your goal is to “cook everything,” that’s useless. But if your goal is to make a better turkey than Uncle Frank’s, you know to focus on finishing the dressing since it’s going into the turkey. A clear Sprint Goal should give you that same kind of direction and help you decide what’s most important.

If you’ve managed to figure out the Sprint Goal, the next big hurdle is knowing when your plate’s full. I’ve seen teams get tripped up here repeatedly—taking on more work than they can chew. It’s like loading up at Thanksgiving dinner: eyes bigger than your stomach. The trick is recognizing when you’ve hit that limit so you don’t wind up with a mess on your plate and nothing to show for it.

How Should Teams Estimate Work During Sprint Planning?

Teams should estimate work during Sprint Planning by exploring various estimation techniques and adopting the method that best fits their complexity, workflow, and context. Many teams think Scrum requires story points, but Scrum doesn’t mandate any specific estimation method.

The Scrum Guide doesn’t prescribe how teams should estimate—actually, it doesn’t even mention the word “estimation” at all.

“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.”
- Scrum Guide

There are several popular approaches to estimation in Sprint Planning.

Estimating in ideal days
Velocity-based planning (in story points)
Capacity-based planning (in hours)
Right-sizing (instead of estimation)

Woody Zuill has suggested that maybe we don’t need estimates. He’s not alone—other prominent voices in the Agile community have echoed this idea. Their argument? Estimates often don’t add value and can lead to misleading expectations. Instead, they advocate focusing on delivering results rather than predicting timelines.

A plant’s roots tightly wound around themselves, with the caption: “Don’t let outdated practices stunt your team’s growth.”

The bottom line is that you shouldn’t cling to practices that aren’t working for your team just because you think they’re part of Sprint Planning. Experiment. Try different approaches. Find what fits your team and gets results. Sticking rigidly to a process doesn’t guarantee success—flexibility and adaptation do.

Treating Sprint Planning as a process with defined inputs and outputs helps frame what the session is all about. It’s not just about showing up—it’s about knowing what you need to address and what should come out of it.

What Are the Key Inputs and Outputs of Sprint Planning?

Key inputs of Sprint Planning include the Product Backlog, team capacity, and past performance data. Outputs are the Sprint Goal, Sprint Backlog, and a plan. Sprint Planning isn’t just about inputs and outputs—the detailed discussions provide clarity and direction.

“The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.”
- Scrum Guide

When a Sprint kicks off, the team should have everything they need to focus solely on achieving the Sprint Goal. Sprint Planning is about clearing as many obstacles as possible and reducing ambiguity around the work. The idea is to ensure enough clarity and alignment to be reasonably confident that the plan will succeed. It’s not about over-planning—it’s about giving the team a solid foundation to start the Sprint strong and stay on course.

When cooking Thanksgiving dinner, having all your ingredients listed and ready is crucial. You don’t want to stop mid-prep to rush back to the store for cranberries or deal with Uncle Fred calling last-minute to add deviled eggs to the menu while you’re knee-deep in making corn pudding. It’s about avoiding those interruptions and staying on track to get everything to the table smoothly and before the nieces and nephews die of starvation.

Now that you know what needs to happen in Sprint Planning, it’s time to get it on the calendar.

When Should Sprint Planning Happen?

Sprint Planning should happen at the beginning of each Sprint before any development work begins. Scheduling events has become more challenging with the rise of remote teams, leading some to defer Sprint Planning—but this choice could spell disaster.

An aerial view of maze with no clear path. Caption:No clear path leads to wandering. A plan keeps you from going in circles.

Sprint Planning should be the first thing that kicks off the Sprint. Some teams prefer to hold it on the first day to avoid unnecessary downtime between the Sprint Retrospective and Planning sessions. This way, there’s a seamless transition and no idle time before diving into the subsequent Sprint’s work.

Your next call is figuring out how many Sprint Planning sessions you’ll need and how long each should be. Don’t just default to what you’ve always done—think about your team’s needs. Sometimes, splitting the session into smaller chunks keeps everyone more engaged.

How Long Should Sprint Planning Be?

The length of Sprint Planning varies between teams, but the Scrum Guide indicates it should be at most two hours for each week of your Sprint. If your planning event consistently exceeds its timebox, it may indicate an issue that requires inspection.

“Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”
- Scrum Guide

Sprint Planning has three main parts: the why, the what, and the how. If your sessions are dragging, break them into these sections. It’ll give everyone time to breathe, grab a bite, and stay sharp. I’ve seen meetings that run over 1.5 hours become mind-numbing and unproductive. Keep it snappy—fresh minds get more done.

Pair of glasses resting on open book. Caption:Sometimes you need to close the book to better understand the story.

Timeboxing your sessions aren’t just a formality but a safeguard. If your planning regularly busts through the set limits, that’s a red flag. It usually means you’re skimping on backlog refinement outside of Sprint Planning. It is better to handle those details upfront, so your planning doesn’t become a marathon session of aimless discussions.

TLDR

A good plan today means you’re not frantically running back to the store for cranberries or scrambling to fix a dry turkey. The same goes for Sprint Planning—nail down the details upfront, and you won’t be firefighting halfway through the Sprint. With a solid plan, you’ll spend more time executing and less time putting out fires.