Planning Rules Rule!

With the Modes of Planning behind us, we now get into the Planning rules.

Typically, when there is a functional system, it has some rules that are followed.

So, let’s have a look at the rules that Planning has. It is actually quite long list of 19 rules, so we will bring you just a few in each article.

The Planning is the first meeting that happens in the Sprint for everybody to know what to focus on in the Sprint.

Planning has a defined time box of a maximum of 4 hours. (An explanation of why it’s 4 hours can be found in our article A Scrum Master's To Do List (Part II).)


Before we start with Sprint Planning, it is a good habit to check the capacity of the team, or their availability for the following Sprint. This helps the team realize how much time for development they actually have.

Take a look at this:

You know, they say Sprints last 14 days. But do you actually see 14 days for development? I do not. And do you know why?

Some of the days are spent in Scrum events—Planning, Review, Retrospective—and sometimes team members take vacation time. In the example above, the Product Owner (PO) has a vacation just before the end of the Sprint.

What does this mean for Developers? They better deliver the work continuously, as they should anyway, so that the Product Owner has enough time to check if the result is what they expected, it meets the Definition of Done and so on.

Also, it is very important before you start the Planning to set the Sprint Goal (how to do that can be found here in this article).

Before we start taking work into the Sprint, the Sprint Goal should be clear. This is so that we can communicate outside of the team what we are focusing on in the Sprint, plus we can check if we are taking the work related to the Goal into the Sprint.

Anyway, let’s get to the rules!

Here are the first two:


The Product Owner can put an upper limit on the amount of work that is planned for the Sprint. The Product Owner has to explicitly state the reasoning behind the limit and the Scrum Master will mark that Sprint as a Pull Sprint.

This is a deviation from Scrum. In Scrum, it is the team's decision how much they pull into the Sprint.

Having this Planning rule and Planning mode in ScrumOne means a certain amount of unpredictability. The Developers are not able to predict the work that will need to be done during the Sprint because there is a buffer for the unpredicted work.

More about this kind of Sprint, what it looks like and its pros and cons can be found here.


The PO, SM and Dev work together to clarify User Stories when needed.

All of that was already described in the Product Owner’s To Do List, the Scrum Master’s To Do List and the Developers' To Do List.

But basically, by this rule, we want to avoid the Product Owner saying, "I provided you all the information I know, so it must be clear to you".


It looks like a big puzzle, right? Well, it is. But I hope you are starting to get the picture, and no worries, there are a lot more pieces to come.

Thank you for reading,

Have courage and be kind.

You may also like:

Modes of Planning (Part IV)

If you read our last article, you might think that it had to have been the last planning mode. What else is there if ad…

Modes of Planning (Part III)

As we promised last time, here we go with another Planning mode. This time it is going to be about ad hoc Planning. This…

Modes of Planning (Part II)

The article we published last time was dedicated to the basic planning mode, Capacity Chosen. In this article we would like to explain the second…