Working without Sprint Goals guarantees technical debt

Sprint Goal Mar 2, 2020

How friction prevents perfect plans and demands the scope of your Sprint to be flexible

Working without Sprint Goals guarantees technical debt

Every Sprint, the Scrum Team comes up with a plan during Sprint Planning. No matter how much time you spend in Sprint Planning or how experienced your Scrum Team, you never end up with a perfect plan. For some reason, your plans are always flawed and need to be adjusted.

Why does it seem impossible to make a perfect Sprint Plan, or any perfect plan, for that matter?

Stephen Bungay, historian and management consultant, studied the big military campaigns of the past to find out what conditions are necessary for strategies to be planned and executed successfully.

Image by Grégory ROOSE

Bungay identified three primary sources of friction that affect the success of your plans:

  1. Knowledge gap. The difference between what we would like to know and what we actually know.
  2. Alignment gap. The difference between what we want people to do and what they actually do.
  3. Effects gap. The difference between what we expect our actions to achieve and what they actually achieve.

There can be other sources of friction as well, such as typical life events, or one or more people on your team becoming ill. But even if nothing out of the ordinary happens, the three sources of friction can never be eliminated entirely. This is why your Sprint Plans will never be perfect. The best you can do is accept that these sources of friction will always exist, and work to lessen their impact as much as possible.

What is the typical response to the three sources of friction?

The usual response to these sources of friction are anti-patterns that generate even more friction, and end up making things worse.

When there is a knowledge gap, people spend even more time on big upfront planning and analysis to try to close the gap. When you do not have enough information to make a plan, no amount of planning or analysis can make you escape the fact that there isn’t enough signal available to use. All that redundant planning and analysis obstructs the ability to respond as new information comes available.

When there is an alignment gap, people are doing something different than what they were told to do. The typical response to alignment problems is to issue more detailed instructions. All these extra details end up obstructing clarity and result in even more confusion.

People don’t do what we want them to do, not because they don’t want to. They do something different because detailed instructions stop making sense when confronted with new and different realities.

The effects gap indicates actions are producing different results than expected. The usual response is to impose tighter controls and metrics on teams to try to ensure they are delivering the right results. By limiting our attention and focus on outputs, the desired outcomes are put at risk.

What is the best way to control the three sources of friction?

Only the Sprint Goal, stated in an outcome-focused fashion, makes it possible for the team to rally behind the strategic intent of the Sprint, and reduce the effect of the three sources of friction. This is why Scrum has a mandatory Sprint Goal every Sprint. The Sprint Goal is the intent of Scrum, and a plan to meet the Sprint Goal is created at Sprint Planning.

The knowledge gap is reduced by the clearly communicated intent of the Sprint Goal. Why and what do we want to achieve? By having that clear overarching goal, new information can be incorporated by teams to make a better plan.

Image by S. Hermann & F. Richter

To bridge the alignment gap, people should be allowed to define what needs to happen and report back on it. This feedback loop is critical to make sure the actions align with the original intent. Each day of the Sprint the plan and progress towards the Sprint Goal is inspected at the Daily Scrum. At the end of the Sprint, there is a feedback loop called the Sprint Review.

To minimize the effects gap, we should give our teams the freedom to adjust their actions based on the intent. In Scrum, this intent is the Sprint Goal. The Development Team should have the flexibility to adjust their plans to meet the Sprint Goal. This is why the Sprint Backlog is flexible during the Sprint as long as you don’t endanger the Sprint Goal.

What is the impact of working without a Sprint Goal?

The Sprint Goal is mandatory when you use Scrum. What happens when you don’t use a Sprint Goal?

When you don’t have a Sprint Goal, it becomes impossible to control the three sources of friction. In fact, the typical responses to friction will impede your ability to respond to the different sources of friction.

When the Sprint has started, the following things are fixed:

  • Budget. Your team will cost the same amount of money and won’t change during the Sprint.
  • Time. The Sprint ends when the time box expires.
  • Quality. Everything that is delivered should meet the Definition of Done.

Therefore, the scope must be flexible.

If you work without a Sprint Goal, the following happens:

  • The intent will be absent. Because the Scrum Team does not understand the main goal of the Sprint, a lot of time is wasted on planning and analysis. Without intent, plans become rigid and inflexible, and it won’t be possible to incorporate new information as more is learned.
  • The Development Team can’t self-organize and define what needs to happen. What needs to happen is defined up-front without a relation to any clear goal. There is no feedback loop during the Sprint to check and make sure we are still going in the right direction.
  • Every Sprint Backlog Item turns into a commitment. As a result, scope no longer is flexible. When the inevitable unforeseen complexity appears, the only way to finish what has been planned is by cutting corners and introducing technical debt.

Prevent technical debt by working with a Sprint Goal

If you want to prevent technical debt, promote teamwork, and control the three sources of friction, you should do the following:

  1. Use Sprint Goals. The Product Owner proposes a Sprint Goal, and the Scrum Team crafts a final version together.
  2. Keep the scope of the Sprint flexible as long as it does not endanger the Sprint Goal.
  3. Let the Scrum Team come up with the plan and allow the plan to emerge and evolve as more is learned and discovered.

If you don’t work with Sprint Goals, you are guaranteed to introduce technical debt, impede teamwork, and prevent incorporating new information as more is learned.

Applying the right focus and giving your team the freedom to make decisions is hard, but well worth it. It’s the only way your Sprint Plan can survive an encounter with the inevitable sources of friction.

Special thanks to Michael Goitein for his valuable feedback and suggestions.