Sprint Planning 2.0 (PWW #9)

This article was originally published in my newsletter Product Whispers Weekly

This week I want to tackle a very common issue in Scrum teams: bad sprint planning. And I'll be honest: I have caused (or at least allowed) my fair share of bad sprint plannings over the years...

The biggest problem with most sprint plannings: they are all about having the team commit to a set of user stories to complete. A lot of time is spent on estimation, calculating potential velocity, taking into account vacations/leave, etc.

There is a whole universe of templates and resources for Scrum Masters and Product Owners to host a "good" sprint planning. But 90% of them completely miss the point.

Most time is spent on trying to plan the work as opposed to planning the value being delivered.

If there is only one thing you take away from this to your next sprint planning:

Focus on setting a clear Sprint Goal, forget about the rest.

But if you want to understand why you should definitely keep reading!

Have a great day ??

Wouter

P.S.: Subscribe now to receive the full newsletter in your inbox every Friday

Why your sprint planning is bad

Let's be honest: sprint planning is terrible. There is a good chance that everyone on your team is dreading it. Seeing it as a "must" instead of being valuable.

I've seen way too many teams where a sprint planning is the lowest energy meeting of the week. Where some poor Scrum Master or Product Owner is trying to make the best of it. But it just doesn't flow and everyone walks away relieved that it's over.

But why? In theory sprint planning should be quite exciting! It's about looking forward, solving new problems and improving the product. Every sprint is a clean slate with plenty of opportunities.

Sprint planning should be flowing, not a waterfall

In my experience sprint planning is often mis-used as an almost waterfall-like planning session. In sprint planning most of the agility from Agile disappears like morning mist on a hot summer's day.

It starts with a Product Owner coming into the meeting already knowing exactly which user stories should be done at the end of the sprint. This is the equivalent of a traditional project manager coming in and laying out the non-negotiable deliverables to a team.

Then there is a Scrum Master with an Excel sheet to calculate EXACTLY how many hours of availability we have for each team member, and perhaps each discipline (frontend, backend, UX, etc).

Inevitably, hours are somehow translated into story points and out comes the magic number of story points the team can take into the sprint.

This results in a game of Tetris trying to squeeze as many user stories into the sprint as humanly possible. Only taking into account the most optimal scenarios, and assuming that estimations are perfect and everything is predictable.

Everyone in the room knows deep down that this is all theater, a charade. But we just have to go through the motions because the Scrum guide says so.

If any of this sounds vaguely familiar, please know you are not alone. And yes there are better ways of doing things.

What sprint planning should look like

So, how can you have a sprint planning be actually valuable? There are a couple of key aspects to take into account.

Create a Sprint Goal

As a Product Owner or Product Manager, this should be your singular focus. You need to be able to lay out an extremely clear goal for the next sprint.

You spend time at the beginning of the meeting talking about the sprint goal, how it relates to the overall product vision, and share the context of how you came to this sprint goal.

Sprint goals don't have a fixed format, but there are definitely good and bad ways to define a sprint goal. Let me give you a few examples of both:

I have seen all of these bad examples in real-life.

The problem is that these goals don't explain why they are valuable.

Finishing the user stories in a sprint is not a goal. You can have a wildly successful sprint by NOT completing all user stories that were "planned", and vice versa.

These are better examples because they are all clear goals. At the end of the sprint it will be quite clear if the goal was achieved or not. You can show this sprint goal to any stakeholder and they will understand what you're working on.

For a sprint goal like this you can already imagine what the corresponding user stories might look like. You will likely need to take several steps to achieve the goal, and there might be experimentation involved.

For example, reducing shopping cart abandon rate is not a black and white exercise. You need to find the root cause, and probably need to launch several experiments to find ways to optimize. That's great because it allows you and your team freedom in determining HOW to get to this result, while still having clarity on WHY we need to get this result.

If you want to dive deeper into the power of Sprint Goals, Maarten Dalmijn has written an excellent book called Driving Value With Sprint Goals.

Don't fill your sprint during sprint planning

This might sound counter-intuitive to you. After all, what most Scrum courses teach us is that the end-result of a sprint planning is a filled sprint backlog.

In reality, what you're trying to do there is impossible. The whole reasoning behind Agile is embracing uncertainty. And nothing is more uncertain than building software.

There is a well-know project management triangle (also called the iron triangle).

There are three aspects to building a product with good quality: Scope, Cost and Time. But here's the kicker: you can only have certainty for two of these at a time, never three. So for example: you can have certainty about Scope and Time, but this means the Cost will be unpredictable or variable. Alternatively, if you want certainty about Scope and Cost, then you lose certainty over Time.

This iron triangle has been in use since the 1950's (!). So these trade-offs are well known. So why is it that in Scrum we are trying to ignore this "law"??

In most sprint planning sessions we are trying to fix all three aspects. Scope (which user stories are in the sprint), Cost (fixed number of workable hours in a sprint) and Time (fixed time duration for a sprint). This is simply impossible. So let's stop trying to do the impossible.

Use sprint planning to discuss as a team HOW to get to the desired outcome stated in the sprint goal. Discuss the user stories that you think are required to meet the sprint goal. But don't assume you know everything at this point. After a couple of days you might uncover information that makes you want to change tactics. There should be room for that in a sprint.

Pull one or two user stories into the new sprint. And whenever a user story gets finished pull in a new one into the current sprint. You transition from a push to a pull model here.

Further reading

I've gathered a couple of bookmarks regarding sprint planning if you want to dive a bit deeper.

Five Ways You're Unintentionally Screwing Up Sprint Planning (Maarten Dalmijn)

Maarten Dalmijn dives a bit deeper into what is screwing up your sprint plannings. Very interesting read, he adds some clever points with regards to velocity planning and embracing uncertainty.

Sprint planning best-practices (Atlassian)

This is Atlassian's high-level guide for running Sprint Planning. They give a nicely nuanced view of what a sprint planning should be. Interesting quote:

For complex work, the level of information you know at the start can be low, and much of it is based on assumptions. Scrum is an empirical process, meaning that you can’t plan upfront, but rather?learn by doing, and then feed that information back into the process.

5 Dos and Dont's During Sprint Planning (Scrum.org)

Scrum.org outlines 5 things you should do in sprint planning, and 5 things to prevent. Good read to see if you are making any preventable mistakes.

?? Subscribe to get the full newsletter in your inbox every Friday

Subscribe to my weekly email newsletter. You will receive the latest edition every Friday, directly in your inbox.

No spam, just weekly interesting reads/videos/podcasts about product management and technology as a whole.