Five Ways You're Unintentionally Screwing Up Sprint Planning

Sprint Planning: The final frontier.

That mysterious meeting with sticky notes all over the place where everything is planned, but it rarely goes as planned.

This happens because most Scrum Teams approach Sprint Planning the wrong way, setting them up for failure from the start.

Here are 5 common ways teams unintentionally screw up their Sprint Planning.

Mistake #1: Plan With Your Full Velocity

Let’s start with a simple example. Imagine this is what our Sprint looks like after Sprint Planning:

The team has an average velocity of 50 Story Points and selects 8 Product Backlog Items that add up to 50 Story Points. At the end of Sprint Planning, everybody pats each other on the back on a job well done. Let’s go!

50 Story Points planned, life is smiling at us and we’ve got no worry in the world. Nothing can go wrong from here.

Except that’s the moment, it all went downhill. You’re making the mistake of planning at full capacity.

Fully loading your Sprint is wrong because no matter how much time you spent preparing, or analyzing before starting, your estimates will be off. By fully loading your Sprint, you’re overloading it. You’re not committing to 50 Story Points, you’re actually committing to 60 or 70 Story Points, because that’s the reality of the work and not what you incorrectly guessed before starting.

This is what your Sprint looks like after Sprint Planning, but it’s unknowable until after you complete the work:

You didn’t commit to 50 Story Points, in reality you committed to 70 Story Points. And just like that… you’re bound to fail from the start and you only discover it when it’s too late.

Of course, sometimes we get lucky, and the actuals will be close to our estimates. Speaking from experience, unfortunately, we usually aren’t that lucky. The inevitable sting of what we didn’t know before starting follows much later somewhere during the Sprint when we lack sufficient time to act upon it. Usually what we discover that we didn’t know before starting represents more work and not less.

And to make things even worse, how wrong estimates can be are capped to your disadvantage. There is a clear floor to how much you can overestimate something, the rock bottom of the number zero. But ay caramba, there is no ceiling to how much you can underestimate something: the sky is the limit.

You can estimate something at 2 Story Points and complete it in a few hours (yay!) or you may complete it in a week because you missed something important you didn’t know before starting.

At the end of the Sprint at the Retrospective, we see mopey faces all around. Our Scrum Team is grumpy because they didn’t accomplish what they set out to accomplish.

But then, the Scrum Team then decides something sensible. Let’s decide to do better! Let’s plan at 70% of our capacity, so we leave some wiggle room for the fact that our estimates will be off.

Smart right? Now let’s see what unfolds before the eyes of our Scrum compadres the next Sprint.

Mistake #2: Plan at 70% Capacity

Let’s say we learned from our mistakes and plan at roughly 70% capacity using our hypothetical example. Here’s what our Sprint looks like after Sprint Planning:

Then the same thing happens: our estimates are off, and we actually committed to 45 Story Points, which is well below the 50 Story Points we should be capable of handling:

But then, the following happens:

• There’s a production issue which we urgently need to handle which is making the company bleed money. It needs to be addressed, stat!

• Another team needs our help to complete something business-critical on time.

• A team member becomes sick during the Sprint.

Then the Sprint ends, and we show up at the Retro, and once again, sad faces are all over. Everybody complains: where did it all go wrong? We left wiggle room for our estimates to be off, and still, we were blind-sided. We didn’t complete everything we wanted to do.

Then, a cunning team member realizes the problem is that we make everything we add to the Sprint the goal to complete at a point in time we have the least understanding.

Mistake #3: Pushing in Work, Instead of Gradually Pulling It In

Our sensible team member realizes the following at the retrospective: “The problem is that we never know what we don’t know before starting. We’re limited by the fog of beforehand: what we can know before doing the work. We don’t know what production issues will come our way. We don’t know which team needs our help with something they can’t figure out. We don’t know what’s technically more difficult than expected. But what we do know is that there will be surprises."

And that’s why we should never make it the goal to complete everything we’ve added to the Sprint because then we don’t leave enough room to deal with surprises.”

After the Sprint starts:

• The scope is fixed. We must complete everything we add during the Sprint.

• Time is fixed. The duration of the Sprint is fixed after it starts.

• Quality is fixed. As described in our Definition-of-Done.

• Resources are fixed (I dislike the word resources, but yeah, that’s a topic for another post).

So, the inevitable conclusion is that we must make scope flexible. Instead of pushing and planning everything at the beginning of the Sprint, we pull in work gradually and keep the scope flexible based on how much work it really represents and not how much we believe it represents before starting our Sprint.

Mistake #4: Making Scope Flexible Without a Sprint Goal

Things are now going a lot better for our Scrum Team. However, the team is not really working together. They are working on a bunch of random things, and whenever there is a problem, they have to ask the Product Owner what they should be doing, instead of acting and being able to make the right decision in the moment.

Pulling work based on a prioritized list still means that your team may not be working towards a common goal, and a team is a group of people working towards a common goal.

The team now decides to pull in the work relating to the Sprint Goal first, as that’s what we’re promising to deliver, instead of promising to deliver everything we pull into the Sprint. Another added benefit is that carry-overs stop mattering. We’re working towards a clear and valuable goal, and if we finish our goal earlier, we’re free to work on other things. It doesn’t matter if those are completed during the Sprint or not.

It’s important to stress that not everything has to relate to the Sprint Goal. However, if things turn out to be more different and complicated than expected, we shift our focus and attention to completing the Sprint Goal.

Mistake #5: Work With a Sprint Goal That Isn’t Agnostic to the Solution

The team is working on a Sprint Goal and discovers that the way the Sprint Goal is phrased relates to the specific solution we’ve chosen. During the Sprint, they discover that the selected solution is no longer viable and will take more effort than expected. They pivot and opt for another solution will be worth to complete.

The Sprint Goal is changed to be agnostic to the solution, and the Sprint is still a success. The team realizes it’s better to formulate the Sprint Goal in a way that’s agnostic to the solution so that once they have a better understanding and more information, they can still amend the solution based on what they discover and learn.

Pushing Wrong Guesses vs. Pulling Based on Actuals

Most Scrum Teams create a traffic jam of work at the beginning of the Sprint because:

1. Their estimates are off, and they push everything in at the beginning of the Sprint, which is the moment you know the least.

2. The reality is that there are always be surprises, e.g. production issues, or other teams needing your help. The only way to accommodate this flexibility is by managing flow and being adaptive. Too much focus on prediction will hamper the ability to collaborate and be flexible as we become anchored in plans that are disconnected from reality.

3. By pulling in work, you work with humble plans. You keep your plans humble and rooted in reality, and as you have better and more understanding, you spend more time planning based on the reality of the work and not what you thought before starting.

4. The goal is to complete everything in the Sprint instead of setting a goal for what we want to achieve during the Sprint. We should make meeting the objective more important than following the plan.

5. Instead of having the Product Owner provide all the answers, provide the team with sufficient context on what we’re trying to achieve and why it matters, so they can make the right decision in the moment. Give the people with the best information the authority to act in the moment by providing them with a clear objective instead of introducing a bottleneck that slows down decision-making and introduces delays. The team is not there to just write code, but to collaborate on achieving a common goal.

It’s pretty simple: focus on pulling and adjusting instead of pushing and predicting. You don’t know how wrong you will be before starting, but after starting, you can discover how wrong you actually were.

The more we try to prevent sucking at predicting, the more we can guarantee to suck at adapting. We inject the fog of speculation in our plans, and our plans become an anchor that make it challenging to respond to reality as it unfolds. Keeping our boots on the ground is what we should care about, not predicting all the steps we will take with our boots before we actually have to take those steps.

Begin with humble plans and set clear Sprint Goals: it’s not about planning less. It’s about planning more when you know more. What we’re trying to achieve should always be leading, not the initial plan we concocted when we had the least understanding.