The consequences of leaving spare capacity for Sprint at Sprint Planning.

The consequences of leaving spare capacity for Sprint at Sprint Planning.

If you work in Scrum, or at least try to, maybe you have faced a problem of not having enough Product Backlog Items (PBIs) ready to be planned for the upcoming Sprint at Sprint Planning. No matter what the reason for that is: too many dependencies between PBIs, unexpected change of business priority, etc… it is always inefficient and highlights a project’s impediments.

Why is it so important to plan amount of work to be performed in the Sprint as accurate as possible?

Scrum inventors are generally very smart guys and even though sometimes some Scrum practices seem to make no sense or we think, can be changed a little bit without any consequences, it’s not entirely true.

Let’s take a closer look at Sprint Planning. The goal of it is to plan the work to be performed in the Sprint, based on the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. If there are fewer PBIs in Product Backlog than projected capacity, then:

  1. we build product value slower than we could and
  2. team motivation decreases

Scrum Guide teaches us that only the Development Team could assess what could be accomplished over the upcoming Sprint. Limitation should be set down by the Team capacity and past performance, not by lack of ready PBIs.

If there is less work in the Sprint than the Development Team can accomplish quite common solution is to make an agreement that once some PBIs are available they will be pulled into the Sprint. At first glance it seems to be a quick and good fix, but be careful of being blind on the root cause of an impediment and converting the agreement to a rule.

Why is it so dangerous?

We all are human beings, we have some strong and weak points, some of us are more determined to do something, some of us are less, but as human beings we all are subject to psychological phenomenon like:

  1. Student syndrome
  2. Parkinson’s law
  3. Pygmalion effect
  4. Hofstadter’s law

Let’s take a closer look at those phenomenon:

Student syndrome– student syndrome refers to an attitude when a person puts off some work till the last possible moment before the deadline, as it is visualized on the graph below

Parkinson’s law

Parkinson’s law says that work expands so as to fill the time available for its completion.

Pygmalion effect – pygmalion effect is the phenomenon whereby higher expectations lead to an increase in performance.

Hofstadter’s law – it always takes longer than you expect, even when you take into account Hofstadter’s Law.


The saddest aspect of those rules is no matter how hard we try to fight with them we will never win, as they are part of our human nature.

So what really happens when we plan a few PBIs with agreement to pull next ones during the Sprint?

First we start quite slowly, as the feeling is that we have plenty of time and not so much work (student syndrome) and because expectations are not very high we don’t perform to our full potential (Pygmalion effect). Even though we assessed that story would take n days, it actually takes n+x days (Hofstadter’s law) to fulfill whole Sprint (Parkinson’s law). Of course this is the worst case, but let’s think of every Sprint you started with free capacity. Was it as efficient as it could have been? Were stories added to the Sprint finished?

Scrum inventors knew about those psychological phenomenon and that’s the reason why: the Development Team is responsible for assessing what could be accomplished over the upcoming Sprint, not lack of ready PBIs.