What Not to Do During the Sprint Planning
By: David Pereira
Tags: Agile, Leadership, Software Development, Product Management, Startup

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

Photo by Lala Azizli on Unsplash

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.

. 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.