How Scrum Masters (and Managers) Go Astray By Committing to Plans

I’ve found only one sane thing to commit to in product.

Imagine your success gets measured on your ability to predict the unpredictable.

Sounds ridiculous, huh? Yet, this is how many default to measuring Scrum Masters and their team’s performance. It’s the rampant, default behavior in organizations today.

We ask our teams to commit to the uncontrollable:

• Estimates of work effort captured as relative story points.
• Completion of the plan and scope from Sprint Planning.
• Completion of a Sprint Goal by the end of the Sprint.
• Attainment of outcomes from all output.
  

Here’s the problem. The number of variables outside the team’s control in product work is massive. It’s like asking teams to commit to predict where a paper airplane will land in a hurricane.

• “We didn’t know that other team had to do part of the work.”
• “We forgot about the brittleness of the code we must change.”
• “The users actually need different features than those planned.”
• “The users aren’t using the perfect solution that we provided them.”
  

These are but a few of the things that can go awry.

We don’t know what will happen in product work until it does.

Committing to upfront estimates and plans is an amateur move.

Why is commitment a bad thing?

After all, it’s considered a sign of trustworthiness. It shows you stand behind your word. You are pledging to fulfill a promise.

But there’s a flaw.

You bet on hope when you make upfront commitments in software product work. You lock in and promise to follow a predefined path at the moment of highest uncertainty.

I made this mistake early in my career. It resolved early pressure to give stakeholders comfort. But it ended up creating massive chaos when we missed big. My teams suffered. My stakeholders suffered. My customers suffered.

Commitments are wishful thinking. They hide the real truth that product work is unknowable up front.

Anyone who’s been in software long enough knows this.

Complexity and uncertainty abound in product, and we can’t control it with a commitment.

No one has ever built the same product twice, with the same team, using the same technology, to serve the same users.

• Will the technology even work?
• How long will this take to build?
• How much will this cost to build?
• Does the team know how to do this?
• Which user’s needs should we address first?
• What feature will actually solve the user need?
• Which solution will a user use and then keep using?
• Will our features have the business impact we desire?
• Will this technology create the experience users desire?
  

With all these open questions, how can we lock time, effort, and scope up front? You got it: we can’t.

Yet, I see Scrum Teams do this all the time because managers demand it.

I watch teams spend hours refining and sizing stories. Forming a detailed Sprint backlog. And committing in blood to deliver it by the end of the Sprint.

Then, performance gets measured based on how they deliver on ridiculous, risk-laden commitments. Detailed tracking spreadsheets, burn-downs, and burn-ups abound. We are measuring the wrong thing, and we get what we measure. We get output (and not very good output) instead of the outcomes we desire.

In the end, teams make pseudo-commitments up front. This only results in grand theater and some award-winning performances. But that’s all it is—great acting with no meaningful results.

Do you want a stage show or valuable outcomes?

To make things worse, when nothing goes as planned, the hiding games begin.

We’ve all seen the charade that follows a missed commitment.

• “Let’s mark this as done, even though it has defects.”
• “Let’s count up our points for the tasks we did complete.”
• “The estimate was too high, but it makes our velocity look better.”
• “We couldn’t help that production went down and interrupted us.”
• “Let’s tell stakeholders we will catch up on our delays next Sprint.”
• “The user told me this isn’t needed, but we committed to doing it.”
• “The other team didn’t finish their task. It’s their fault we didn’t finish.”
  

Committing up front is the moment of highest ignorance. It leads only to blame, cut corners, and reduced transparency.

It’s like promising to win a game you’ve never played before. You have no knowledge of the rules, the plays you can run, or what pleases the crowd. It soon becomes clear you can’t win. Then, you start making careless mistakes and throwing penalties out of desperation.

An upfront commitment is the promise of product failure and unpleasant stress.

The only sane thing you can do: commit to learning your way to a valuable outcome.

Commit to learning? That sounds so hippy-dippy.

But it’s not. The Scrum Teams I’ve seen who focus on learning have discipline. They are among the most reliable, trustworthy teams on the planet. And they deliver exactly what’s needed, in the right way, in the time that it’s needed.

How is it possible to deliver what’s needed sooner when you don’t deliver to a plan?

Let’s unpack this a bit. A few product truths I’ve noticed over my long career in software:

• You don’t know what you don’t know until it happens.
• You don’t know what will work for your customers until it does.
• You won’t know the best way to build it until you are building it.
  

I’ve found it’s impossible to know the right plan beforehand. Action and learning from action are far superior. But for this to work, my learning loop needs to be small and fast. I learn after every step and use that knowledge to inform my next step. All the while, orienting to the customer and stakeholder need I am solving.

I have to respond to the terrain over keeping my head stuck in a map.

Scrum Masters, this will work for you, too.

Your early steps to your goal will be shaky. You will go down bad paths. But reorienting after each step keeps you from falling off a cliff.

When you expect the unexpected, you can adjust to it faster.

When teams start relying on what they thought they should do before they started, they lose. Instead, they should rely on what they think once they’ve started. Evidence leads to thinking. Thinking leads to learning.

Plans go stale fast in product work.

Upgrade your approach. Let the results of your actions determine your next action.

You’ll arrive sooner with learning.

My 8 Steps to Embrace Learning Over Commitments to Plans

Let’s get tactical on how I’ve seen teams move to relying on learning instead of risky commitments.

Here are 8 actions you can take today to start putting learning first:

1: Options, not scope. Instead of referring to your backlog as your “scope of work,” refer to it as options. This is a simple shift of language, but it changes your entire attitude to the finality of your planned work.

2: Pull one option at a time. Why would we pull a big batch of work into a Sprint at the beginning given all the uncertainty we face? Instead, pull one small option at a time as a team. Complete it. Learn along the way. Use the learning. Then, pull the next option.

3: Reduce your planning horizon. Yearly planning is too long of a horizon. So is quarterly and monthly. Sprint Planning for a two-week Sprint should be fine, right? No way. I’ve seen much go wrong in two weeks. A day? This is not bad, but we can do better. The smaller our step, the less can go wrong. A planning cycle of an hour or less seems to be a sweet spot to take learning to its zenith.

4: Expand what it means to be “done.” When a team builds a “shippable” feature, the work is not done. How about when features get shipped? No, go farther. When it is being used by a user? This also falls short of the outcome and impact we seek. We can claim victory only when the user delight emerges and we have an impact that works for our business. The only way we can get there is by committing to the crooked path that relies on learning.

5: Start saying, “I don’t know.” These three words bring terror to Scrum Masters and managers everywhere. But humility goes a long way to reprogram the organization to embrace uncertainty. If we keep acting as if we know by committing to the unknowable, the illusion will persist. Pop the bubble of unrealistic expectations.

6: Measure learning, not your ability to predict. By measuring committed versus actual, you keep the false hopes alive. You give the impression that you can improve your predictive powers if you only try harder. We have to stop this fairy tale. Measure something that matters, such as your learning loop speed. How fast you learn is a superior predictor of your ability to reach an outcome.

7: Be a learning evangelist. By embracing learning, you are confronting a corporate beast: the hunger for control. This means you must educate, train, and evangelize the beauty of learning. Inspire in others the desire to change. Once you have this, you can move to the final step.

8: Put on your lab coat and show evidence. You’re going to have to prove learning is better than predicting up front. You’d think this wouldn’t be the case, but it is. We have to meet the organization where it is. Start with a small experiment to hurry the proof. This provides the benefit of illustrating the beauty of small steps. It shows immediate results and the speed of learning. And it allows the organization to reap any outcomes right away.

---

So, in summary, stop the plan commitment circus.

Moving away from upfront commitments is a crucial step to make Scrum a valuable framework. Scrum Masters play a big part in making this happen. So do managers.

You have to give up the illusion of control and any measurement of the illusion. A measured illusion is still an illusion. Don’t fool yourself (or others) into believing otherwise.

Instead, go all in on learning.

A crooked path will emerge.

That’s OK.

You’ll reach your destination sooner and safer. Your customers will smile. Your organization will count the cash. Your team will stand proud.

Remember, Scrum is a learning framework, not a precision-aiming one.

Good luck out there. Keep on learning.

---

➡️ Sign up for weekly tips like this on doing more with less while respecting people.