Same word. Same team. Opposite effects.

How did commitment—a word that gives energy in the morning—become a word that drains it by Friday? And what happens to a team when this goes on for months?

The Dashboard That Killed Innovation

I coached a team where this exact scenario played out over the course of several sprints. The story doesn't involve villains. That's what makes it dangerous.

• Sprint 1 — The Good Intention The engineering manager—let's call him Thomas—built a dashboard. One metric, front and center: Commitment Respect %. Take the story points pulled into the sprint during planning, divide by the points delivered, multiply by 100. Above 90% meant reliable. Below 80% triggered a conversation. Stakeholders loved it. Finally, a number they could track.
• Sprints 2–3 — The Drift Sprint Planning conversations shifted. Before the dashboard: "Given what we know, how much can we reasonably accomplish?" After the dashboard: "How much can we promise without risk?" Those two questions sound similar. They are fundamentally different. Estimates started inflating. A 5 became an 8—not because the work was harder, but because the padding reduced risk. Ambitious items disappeared from the Sprint Backlog. Not because they weren't important, but because they were dangerous.
• Sprints 4–5 — The Vicious Cycle Commitment Respect: 97%. Then 98%. Thomas showed it proudly in leadership meetings. But real throughput was declining. The team was delivering less actual value than before the dashboard existed. Senior developers stopped proposing technical improvements. Laura stopped bringing up a critical refactoring of the notification service. "It's risky work—hard to estimate. I can't afford to blow the commitment number." She wasn't lazy. She was rationally responding to the incentive system.
• The Moment of Truth Sprint 6. A production incident exposed a performance bottleneck in the notification service—the exact system Laura had wanted to refactor. Two days of partial downtime. The post-mortem traced the root cause to accumulated technical debt the team had been aware of but hadn't addressed. Thomas was confused: "The team's been hitting their commitments. How did we miss this?" The answer was uncomfortable: they hadn't missed anything. They'd done exactly what the system incentivized them to do.

Innovation didn't die in a dramatic explosion. It died quietly, in the space between "I had an idea" and "never mind, it's not worth the risk."

Why the Same Word Produces Opposite Effects

The root of the problem isn't the dashboard. It isn't Thomas. It isn't even measurement. The problem is that the word commitment means two completely different things depending on who says it and in what context.

Daily commitment is voluntary, short-term, self-declared, and adjustable. Laura says "I commit to finishing this today" and she owns that promise. If circumstances change, she adjusts at the next Daily. No one punishes her for revising her plan. The commitment is a focus tool with a 24-hour horizon, and the only person who can declare it is the person doing the work.

Sprint commitment (as it was being used on Thomas's dashboard) is externally measured, spans two weeks, gets turned into a KPI, and shows up in performance conversations. It's not a personal focus tool anymore—it's an implicit contract between the team and management.

That reversal is the mechanism that turned Thomas's well-intentioned dashboard into an innovation killer. And if you're using a "Commitment Respect %" metric right now, you should be asking yourself: is this happening to my team?

The Scrum Guide 2020 Pivot

The Scrum community recognized this problem. In the 2020 revision of the Scrum Guide, the language around sprint planning changed formally and deliberately.

The word commitment was removed from the Sprint Backlog. In its place: forecast.

This wasn't softening the language. It was precision. The Scrum Guide drew a clear line between two different concepts:

• The Sprint Goal remains a commitment. The team commits to a direction—a coherent objective that gives meaning to the sprint. This commitment is real, firm, and the team should fight to achieve it. The Sprint Goal is the why.
• The Sprint Backlog items are a forecast. They represent the team's best current plan for achieving the Sprint Goal, based on what they know at the time of planning. This forecast is expected to evolve. The Sprint Backlog is the how, and the how is allowed to change.

Think about it this way: a weather forecast of 30% chance of rain isn't a failure if it rains. It's information that was accurate given what was known at the time. If your meteorologist was penalized every time their forecast was "wrong," they'd start predicting 50% chance of rain every day—technically never too far off, but practically useless.

That's exactly what happens to teams whose sprint forecasts get treated as commitments. They optimize for being right, not for being useful.

Making the Shift — Concrete Levers

Understanding the problem is one thing. Changing the behavior is another. Here are four concrete levers to make the shift from commitment-as-contract to forecast-as-tool.

At Sprint Planning: Reframe the Question

Stop asking: "What do we commit to this sprint?"

Start asking: "Based on what we know today, what's our forecast for achieving the Sprint Goal?"

The first question implies a fixed scope that must be defended. The second implies a best-effort plan that will be refined as the team learns. It gives the team permission to be honest about uncertainty—and honest estimation is the foundation of useful sprint analysis. The stronger your Refinement process, the less uncertainty you carry into planning—but there's always some, and pretending otherwise is the first step toward padding and sandbagging.

With Management: Replace the Metric

If you have a "Commitment Respect %" dashboard, consider replacing it with two metrics that actually drive useful behavior:

1. Sprint Goal Achievement — binary. Did the team achieve the Sprint Goal? Yes or no. This measures what matters to the customer: outcomes. It doesn't penalize the team for adjusting their plan along the way.
2. Scope Stability — items added or removed during the sprint. This measures the quality of planning and the stability of the environment. High scope change might indicate poor refinement, shifting priorities, or too many unplanned interruptions.

The distinction between what was forecasted and what was injected tells a much richer story than a single commitment percentage ever could.

At the Daily: Keep "Commit" Here

Here's the nuance that gets lost in the conversation: the problem isn't the word commitment. The problem is using it in the wrong context.

At the Daily Stand-Up, commitment is in its natural territory. "I commit to finishing this by tomorrow's Daily" is a personal focus tool. It's voluntary, short-term, self-declared, and creates a deflection mechanism that helps developers protect their time. Keep it. Don't throw the baby out with the bathwater.

The Daily is where commitment lives. The Sprint is where forecast lives.

In the Culture: Redefine "Wrong"

Under a commitment culture, a wrong estimate is a failure. Under a forecast culture, a wrong estimate is information. The forecast was off, which means the team has something to learn. The response is curiosity: "What did we learn? What was different from what we expected? How does this change our forecast going forward?"

This is the A3 thinking mindset applied to estimation: every gap between expectation and reality is a learning opportunity, not a performance problem. Teams that internalize this get better at forecasting over time—not because they pad their estimates, but because they genuinely understand their own capacity and the nature of their work.

What Changed

After the production incident, Thomas and I sat down to redesign the dashboard. The old Commitment Respect % came down. In its place went two new indicators: Sprint Goal Achievement (yes/no, per sprint, displayed as a streak) and a Scope Stability chart showing items added and removed mid-sprint.

The first thing that happened was uncomfortable. The Sprint Goal achievement rate was lower than the old Commitment Respect %. The team had been hitting 97% commitment respect but only achieving their Sprint Goal about 70% of the time. The old metric was masking the real performance by rewarding safe commitments to easy work.

The second thing that happened was better. Laura brought her notification service refactoring back to the table. "It might take longer than we think," she said during planning. "But it directly supports the Sprint Goal of improving system reliability." The team pulled it in—not as a promise to complete, but as their best plan to achieve the goal. They finished it in a sprint and a half. Under the old system, that would have been a red number. Under the new system, the Sprint Goal was achieved.

Thomas's dashboard still exists. It still gets shown in leadership meetings. But now it tells a story about outcomes and learning, not about compliance and control. The dashboard went from green-and-meaningless to occasionally-yellow-and-useful. Thomas calls that an upgrade.

The best teams don't commit to task lists. They commit to goals, and forecast the rest.