February 10, 2020

Sprint Plans are Worthless, but Sprint Planning is Everything

Dwight D. Eisenhower, the World War II leader and U.S. President, wrote: “[...] plans are of no particular value, but [...] planning is indispensable”.

It’s a powerful phrase that aligns all so well with Scrum. Contrary to a myth that there is no planning in Scrum, planning is actually everything: we plan our work not only in Sprint Planning but also every day at Daily Scrum. 

However, it is the plans that we make that are less important: we use them to guide our decisions initially, but we do not stick to them if it doesn’t make sense. Daily Scrum is there to make sure we replan at least once every 24 hours. 

So to continue this analogy, I’d like to talk about a common myth that gets brilliant teams stuck in their Sprint Planning feeling overwhelmed.

 

Myth: You have to plan the whole Sprint in Sprint Planning

The Scrum Guide says: The work to be performed in the Sprint is planned at the Sprint Planning

Many teams use Sprint Planning to plan their tasks in detail from start to finish: who will work on what and how much time each task is most likely to take. 

This often turns the Planning session into a painful boring meeting where people create to-do lists for each person on the team. Because those lists are quite detailed it usually takes all the team’s energy and plenty of time to do.

I see it all the time: teams try to fill in their Sprint Backlog for the whole Sprint with work, taking items from the Product Backlog and breaking them up.

And, unfortunately, it usually never turns out the way it was expected according to plans. I think this is easily the most frustrating part: when you realize that all that time spent sitting in a room creating a detailed plan was wasted when new information comes up.

The problem lies not in the act of planning itself, but in the way we do it. As in the quote I mentioned above, remember that plans are worthless, but planning is everything.


 

Long-term plans accuracy

Now let’s imagine you’re making plans for the year. You set up your goals, let’s say it’s something like ‘establish a healthier lifestyle’. I guess, now you have to plan for the whole year. You need to know what exact things you are going to do during all 12 months ahead, and you’re trying to be as specific as possible. Say, you decide all the half- and full marathons you will run, on which dates, and where, as well as plan for all the meals you’ll be eating for the rest of the year.

That obviously sounds quite unreasonable, doesn’t it?

Firstly, it’s such a long period of time, that you won’t spend days creating a perfect plan. Secondly, you understand that life might get in a way of your plans, and if you sign up for a marathon happening in 12 months from now, you might not actually make it just because of a number of unforeseen circumstances. And what if you find out that a certain type of diet just doesn’t work for your body? Your full-year-healthy plan just went to waste, so is the time you spent creating it. 

Quite naturally, we don’t try to be too precise when we plan for a long period of time. We only set up clear goals and adjust. 


 

One Sprint is a long-enough period of time

Creating a detailed to-do list for the whole year sounds ridiculous. But Sprint is a short period of time, less than a month, so we should be able to plan for it, right?

Well, not really. 

One month or even two weeks is a long period of time in a complex product development environment. Even one day can be too long.

What really makes it difficult to plan is not time alone - the complexity comes from the uncertainty of the task itself. So something that was initially planned to take one day might take a whole week because of something uncovered after the work started.

In that matter, a whole Sprint is a very long period of time, having a detailed plan for it as ridiculous as having a detailed plan for the whole year.

Sprint Plans are worthless, Sprint Planning is indispensable


 

The right way to do Sprint Plans

The activity of planning for the Sprint is still essential, just don’t get too attached to your Sprint Plan. As you know that your Sprint Plan will most likely change, spend just enough time and effort on it and not a second more.

To do it right, you have to start with a Sprint Goal. Same as in the year-plan example, having a goal is what keeps it all together. Spend some extra time on this step, because it is much more important than creating the plan of tasks for the Sprint!

Then use the time left in your Sprint Planning timebox to plan just enough work to get started: a few days’ worth of work is just enough. You can have a general idea of what else can be done in the Sprint, but don’t waste your time trying to be precise.

If the team runs out of work that has been planned, you can plan some more work. Luckily, with a clear Sprint Goal defined and new information you’ve collected in the first days of the Sprint, your plan will be more valuable this time. 

Set some time aside after your Daily Scrum to re-plan the work with the team, and once again, don’t try to plan for the rest of the Sprint right away. Plan just enough work to get you going and re-plan as soon as the need arises.

This method of planning can also be called “just enough just in time”. It allows your Scrum team to detach themselves from the Sprint Plan itself and bring more focus to the Sprint Goal. 

After all, Sprint Backlog is emergent and it changes, while the Sprint Goal remains the same for the whole Sprint. 

 

 

When you change the focus of your Sprint Planning from creating a plan to planning for change, you can achieve higher benefits of implementing Scrum.