What Not to Do During the Sprint Planning
Until the Sprint Planning is meaningful, the Scrum Team cannot deliver significant results.
Until the Sprint Planning is meaningful, the Scrum Team cannot deliver significant results.

After a stressful Sprint, the Scrum Team was ready to start the Sprint Planning. Developers were eager to collaborate intensively and build something meaningful. But the mood went down after a couple of questions from the Product Owner:
How many story points did we deliver last Sprint?
How many story points can we commit to this Sprint?
Is there any urgent technical debt we should solve now?
The developers were frustrated because they knew what was to come. They didn’t want to build features just for the sake of building them. Björn, one of the developers, was furious. He couldn’t stand it anymore; he urged:
I feel like we are locked in a vicious circle. Sprint after Sprint, we do the same stuff. I cannot keep going on in this senseless way anymore. We have to address some questions:
Why do we always prioritize multiple features instead of a single goal to pursue?
Why do we care so much about story points and ignore the outcome we want to realize?
Have you ever been in a similar situation? Unfortunately, many Scrum Teams face similar problems. If Sprint Planning doesn’t contain the essential ingredients, you cannot expect a meaningful result.
“Sprints are the heartbeat of Scrum, where ideas are turned into value.”
— The Scrum Guide, 2020
Let me share with you some insights of what not to do during the Sprint Planning. Honestly, I’ve already fallen victim to all the traps I’m about to describe.
If you are interested, you could also watch the following video on my YouTube channel. I hope you can benefit from the insights I share.
Delivering Multiple Features Is the Ultimate Goal
Stakeholders pressure Product Owners to fulfill their wishes. If Product Owners don’t know how to handle this pressure, they will inevitably be incapable of defining a Sprint Goal. Unfortunately, the result is nothing less than chaos because:
Developers have no chance but to run in different directions, which reduces the ability to collaborate.
Commitment is done on the feature level. If a single feature isn’t finished, stakeholders are furious.
The Scrum Team becomes an ordinary group of people because they don’t have a shared goal to pursue.
It’s simple to avoid this confusing madness. Never start a Sprint without the Sprint Goal. First comes the goal to pursue, then you can discuss which Product Backlog Items will let you achieve the goal. The Scrum Guide makes it simple to understand. Let’s look at it. In bold, you can read the relevant parts.
Topic 1: Why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.
— The Scrum Guide, 2020
Plan Based on Capacity
I used to be obsessed with story points. I believed that by increasing the number of story points delivered, we maximized the value. Well, I was wrong. The story points don’t matter at all; what matters the most is changing the end-users’ lives for the better.
During the Sprint Planning, I wanted to know how many story points we could commit to. My advice to you is simple: don’t do that, please. The Scrum Team commits to the Sprint Goal. Story points don’t really matter. What matters is achieving the Sprint Commitment.
I realized that I behaved as a Project Manager, trying to plan resources instead of setting goals. Our mission as a Product Owner is to lead the Scrum Team to building something meaningful. If you focus on the story points, you will miss the mark.
The team realizes the only way to keep stakeholders happy is if their velocity obeys the laws of the universe: ever-expanding. And they know this isn’t something they are able to keep up indefinitely.
— Maarten Dalmijn, Companies That Obsess Over Velocity Are Clueless About Scrum

The Dangerous Balance
In 2017, I started a new job as a Product Owner. The CPO told me: “When you plan a Sprint, you should utilize the teams’ capacity as follows: 50% new features, 20% technical debt, 20% bug fixing, and 10% slack time.” When I heard this sentence, I was puzzled. I wondered, “How developers would be able to act as a team.”
After a couple of weeks, I realized, developers couldn’t function as a team due to the considerable Sprint segmentation. We had no focus. Once again, I felt like a Project Manager striving to plan resources perfectly. I think that Product Owners should challenge the status quo because most companies are clueless about agile.
I couldn’t accept the CPO’s approach. I thought, “Why do we always have to invest 40% of our time fixing things? Shouldn’t we find the root cause and avoid producing bugs and technical debt in the first place?” I also didn’t like the idea of 50% to focus on features. For me, something was missing: the Sprint Goal.
“The biggest thing I’ve learned in product management is to always focus on the problem. If you anchor yourself with the why, you will be more likely to build the right thing”
― Melissa Perri, Escaping the Build Trap: How Effective Product Management Creates Real Value
As the Product Owner, you should craft a compelling Sprint Goal with the Scrum Team. Keep in mind that developers are self-managing; if they need to fix technical debt, they will organize themselves to do so.
I learned the hard way that segmenting the Sprint end in dreadful results. To put it simply:
Without a clear goal to pursue, Scrum Teams are like dogs chasing their own tails.
Unprepared Product Backlog
The Sprint Planning is the moment to decide how to move forward. It’s not the moment to refine Product Backlog Items. That’s why it’s crucial to have the Product Backlog ready for the Sprint Planning. Otherwise, the event will become a mixture of planning and refinement, which is exhausting. I’ve done that more than enough to conclude it’s a horrible experience:
It’s too much to do in a short time. Refining and planning are different spectrums. While refining, we focus on understanding the problem. During the planning, we focus on achieving the goal.
The Scrum Team might start the Sprint with a low motivation due to a stressful Sprint Planning.
For me, not having enough items in the Product Backlog for the upcoming Sprint is as bad as having an extensive Product Backlog. I believe that somewhere between two and four sprints is a good size for the Product Backlog.
The Product Owner is accountable for the Product Backlog. As a Product Owner, it’s your role to ensure the Product Backlog Items are relevant to achieve the Product Goal. Don’t keep items that are irrelevant to the Product Goal.
If you want the Sprint to start smoothly, you have to ensure the Product Backlog is prepared for the planning.
How to Rock During the Sprint Planning
The Sprint Planning is vital for the success of the Scrum Team. Without a decent Sprint Planning, the result won’t be satisfactory.
“All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.”
— The Scrum Guide, 2020
It’s easy to get a great outcome from the Sprint Planning if you do what has to be done. It’s like cooking; if you have the right ingredients and follow the recipe, you will end up with a tasty meal. The recipe for the Sprint Planning is simple:
Why is this Sprint valuable? Focus on understanding how the Sprint will help achieve the Product Goal. Then, craft the Sprint Goal.
What can be done during this Sprint? Once you have the Sprint Goal, define what you should do to achieve the goal.
How will the chosen work get done? Developers plan the work for each Product Backlog Item. It’s the moment to define how the solution will be implemented.
Don’t underestimate the importance of Sprint Planning. That’s the beginning of either a successful or a terrible Sprint.
Do you want to write for Serious Scrum or seriously discuss Scrum?