Are Your Scrum Sprints Becoming a Backlog in Disguise?

Are Your Scrum Sprints Becoming a Backlog in Disguise?

girls sitting on rail

Scrum is complex. We all have an “ideal world” in mind as we approach critical projects, but despite our best intentions, reality seldom follows. We can clearly see that some aspects of our Scrum implementation on our current project are not ideal, despite following all the ceremonies to the letter. It just does not work, and we cannot put a finger on a single cause.

Let us take a look at one common symptom of a malfunctioning Scrum process: a lack of motivation for planning meetings. Your team is smart, and recognizes meetings that are not very useful for them. If the problem is not your team, then what is it? This might sound far-fetched, but perhaps the issue can be found in your definition of a sprint.

What Is the Goal of a Sprint? 

This is one of my favorite questions to ask a client in the first interview, because it reveals so much about a client’s approach to Scrum as well as the relationship between the business and development teams. A common answer is, “The goal is to produce as many story points as possible.”

To me, this indicates that the company is looking for heroes who sacrifice themselves for the project. However, this method is hardly sustainable; it’s a very short-sighted approach to a project that might run for several years. Calling out for a hero means that the team will be inclined to add more stories to the sprint than they expect to finish. In the long-run, fewer sprints will be more successful.

Let’s back up one step and reframe the question:

What Is a Successful Sprint?

If the answer to this question is something along the lines of “Seventy-five percent of the stories are finished,” this means trouble. This approach is even worse than the aforementioned maximization of story points, because the team will stop questioning their approach when they hit that 75 percent mark. As a result, the team will stop learning.

But even if the answer is “One hundred percent,” and even if your team is very good at estimating story points, there is a problem. If you expect the team to hit their average number of story points half of the time (see Figure 1), they might feel pressured to be faster and work overtime (as opposed to producing more value for the customer—which is not necessarily the same thing), or take shortcuts on quality (testing and documentation).

An indicator for this problem is that stories finish late, often just before the end of the sprint.

Even if you safeguard the team, forbid overtime and keep quality standards, it’s likely that the team will miss their expected goal and you will end up with an unfinished sprint.

bell curve

Figure 1: Bell curve showing the distribution of the time needed to finish all the stories of a sprint. Reducing the sprint size will significantly increase the probability of finishing a sprint within the sprint.

Now, what is so bad about the team just managing to get 50 percent of the sprints done successfully? That sounds like a good percentage, right?

A Slow but Deadly Poison

Unfinished sprints are a slow but deadly poison. They will hamper the planning meetings and ultimately the entire Scrum process in three ways:

  1. With many failed sprints, the team loses their feeling of accomplishment. An unattainable goal is as good as no goal—ultimately, over-ambitious goals will make people ignore sprints and instead focus only on assigned tasks.
  2. You have added overhead for additional planning. Stories that are worked on over the course of many sprints become more expensive, as their business value remains unrealized and team members must remember again and again what they were about. They also slow down planning of new tasks and impede the focus of the team when selecting the next story to work on.
  3. There is constant pressure from the product owner. If the team decides which tasks to work on and in what order, "uncomfortable" (but maybe valuable) tasks might remain unfinished (there is always something "more important" coming up) and dragged along to future sprints. The product owner then must require team members to conduct work in a specific order, and the concept of a sprint again loses its meaning—becoming more like the backlog—and the team loses its sense of responsibility for the sprint.

100 Percent Workload Is a Traffic Jam

Ultimately, it is "management thinking," the idea that 100 percent workload of the team will maximize the business value of the project, that is the cause of sprints being abandoned in favor of the backlog. In that regard, a production process can be compared to a road. On a road, 100 percent workload is called a traffic jam. You can maximize the efficiency of a road only by using more efficient vehicles: more people per car instead more cars. In that regard, buses could be called the “sprints” of the road.

To profit from the advantages of Scrum, keep a buffer of 10 or 20 percent. If your sprint runs two weeks until Friday, plan sprints so that the team is finished on Thursday and free on Friday. From a management point of view, this idea has a scary outlook: your team has completed its work, now what? Do you send them home? Do you have them start another sprint? Do you add new stories to the completed sprint?

It is important to get away from the idea of 100 percent workload being optimal. That is local optimization for a global problem. When the team is done with the sprint, the team is done! Let the team decide what to do with the remaining time.

People are self-motivated, and they generally like to learn. Give them the opportunity to read books, attend conferences or seminars, research recent technologies or just take a break. Use the time for team building, improving the office atmosphere or generally cleaning up things that have piled up (there is always something!). Encourage them to discuss what projects or program parts could be scrapped.

But, most importantly, let it be the team's time. Set the completion of sprints as the goal and allow the team to celebrate their success.

If you are afraid that, with such a positive outlook, they will aim for less and less each sprint, re-examine your own views and ask yourself: “Why are they not motivated to work on the project?” Asking that question is much more productive than trying to coerce your team into working more, which usually just means having them spend more time in the office staring at their computer screen without any tangible increase in productivity.

Don't Just Ask Why

You might even want to try not just asking “Why?” once, but five times, just as Taiichi Ohno did at Toyota, until you find out the actual reasons for their lack of engagement. The team must lead the project; it is theirs. If you are uncomfortable with that idea, perhaps agile methods are not for you. But, if you want to tap into the power of agile, it is essential that the team feels responsible for the product.

Ultimately, like many elements of Scrum, this approach will reveal the actual problems you have in your company. In other words, existing non-agile business processes are seldom “accidents” that are just waiting to be replaced with Scrum. They are the result of a multitude of related problems which can, with Scrum, be named and discussed objectively.


The team lacks motivation for planning meetings.

  • Aim for 100 percent sprint completion instead of trying to maximize your story points per sprint.
  • Have the courage to plan for fewer story points than what the team can manage on average.
  • Use extra time to finish outstanding tasks, to refactor or to learn about new technologies.

Have you ever seen or experienced a sprint that was more like a backlog? Do you use other methods to make sprints more efficient? Let me know in the comments section below.


Clemens Lode is the founder of LODE Publishing

Learn More
comments powered by Disqus