The Scrum Guide says that a Scrum team makes a forecast during Sprint Planning, but managers want a commitment. What’s the difference and why is a forecast much better than a commitment?

The Problem

Promises and pie-crusts are made to be broken.
-Jonathan Swift , Irish satirist, 1677-1745

When a Scrum team makes a commitment, they are making a promise to deliver a certain amount of work by the end of a Sprint. Of what use, however, is a promise? Between the inevitable requirements changes and the unexpected technological glitches, how sound is any commitment the team makes?

Then there’s the forecast.

“There are two kinds of forecasters: those who don’t know, and those who don’t know they don’t know.”
― John Kenneth Galbraith

And there’s the problem. We need to deliver, but we know we probably don’t know exactly what can be accomplished by the end of a Sprint. Therefore, does requiring the Scrum team to make a commitment really make any difference? Does it make it more likely they will deliver what they say, when they say?

Clearly, no.

Commitment Make it Worse

I don’t think it comes as a big surprise – requiring a Scrum team to make a commitment makes the situation worse. The Scrum team knows they are making a best guess – as a promise.

Sometimes a commitment makes the problem worse because the Scrum team puts less work into the Sprint in order to be sure they can meet their commitment. So, they meet their commitments, but how much potential productivity are we sacrificing as a result?

What makes it even worse is the behavior Scrum teams engage in when are measured against one of the most useless metrics on the planet: the amount of work done over the amount of work committed.

In other words:

total work done / total work planned

This metric is supposed to encourage teams to finish everything they plan. What it does instead is ensure the Scrum team does one of the following:

  1. undercommits the Sprint,
  2. inflates their estimates,
  3. cut corners on quality to get everything done,
  4. works unhealthful hours to get everything done, or
  5. gets really lucky and hits the commitment.

A one in five chance of the right thing happening is not a great plan.

It Gets Worse

As hard as it may be to believe, the story actually gets worse. When Scrum teams have to commit work into a Sprint, they tend to:

  • Create an overly detailed sprint plan in order to be more likely to hit their commitment.
  • Not plan at all because they “don’t have time to plan.”
  • Ignore a variety of potential solutions for a given problem, missing opportunities to reduce cost and effort.
  • Ignore alternative approaches to problems during the Sprint, staying focused on either the plan made at Sprint Planning or, lacking a plan, just working hard to get things done.

In other words, by having a commitment the team must reach by the end of the Sprint, they are more likely to exhibit behaviors that make it harder to get work done in any kind of effective manner.

What Can I Do?

Good question. The answer, like Scrum, is simple to understand, but difficult to truly master. You’re going to have to do something your organization may not be culturally prepared to do:

Embrace the Goal, Change the Plan

Take a look at the Scrum Guide. There are 19 references to the Sprint Goal but only 12 references to the Scrum Master. There’s a reason for that.

“Jim’s First Law of Planning”

This is a good time to introduce you to my first law of planning:

You know the least about a plan at the moment you create it.

There’s an important corollary to this law. It goes like this:

All plans are wrong.

Another corollary comes right from the Agile Manifesto:

The best architectures, requirements, and designs EMERGE from organizing teams.

This isn’t just a pretty sentence. It’s a fundamental premise. When we build an architecture definition, it’s wrong. When we build a requirements document, it’s wrong. When we create a design, it’s wrong. Why? Because we know the least about it when we create it.

Think about it. Have you ever seen a requirements document that didn’t change? An architecture that didn’t change? How about a design that didn’t change? Of course not.

Sprint plans, created during Sprint Planning are wrong. Why? Because we know the least about what’s going to happen in the Sprint during Sprint Planning.

Do you know what doesn’t usually change during the Sprint?

That’s right, the Sprint Goal.

So, how does this all come together?

The Answer to the Problem

Scrum teams (all development teams, really), need to be focused on goals, not plans. When planning a Sprint, take the time to get the Sprint Goal right (for more on this, see my other posts, here and here). The actual sprint plan should be considered a forecast for what the team is going to do to achieve the goal.

At the beginning of Sprint Planning, the Scrum team should decide what needs to be accomplished by the end of the Sprint. What kind of functionality should be done? What kind of problems should be fixed? Then, the team incorporates the product backlog items into the Sprint that best accomplish the Sprint Goal. However, if something impedes the developers from completing the plan, they should feel comfortable changing or even completely scrapping the Sprint plan. There are an infinite number of ways to accomplish a goal. The team shouldn’t be stuck with the backlog items they loaded into the Sprint and any plan they created to get them done.

In other words, it’s the GOAL that’s important, not the plan. It’s the GOAL that’s important, not the backlog items. At the outset of the Sprint, we KNOW the plan is wrong. But the goal is usually valuable and achievable in a number of ways. Even if we can’t achieve the goal, the closer we get, the better.

Summary

For our Scrum teams to be more effective, we need to

  1. set a good, clear Sprint Goal at the beginning of the Sprint (this is done in Sprint Planning, part one)
  2. recognize that, because of the many variables present in complex work, plans are always wrong and should be considered subject to change
  3. look at the plan as a forecast, but be willing to scrap it when a new approach is needed (by the way, the purpose of the Daily Scrum is to validate the Sprint Goal every day of the Sprint)