Scrum Sprint "Commitment" is Pure Bullshit

I've never seen sprit "commitment" or "forecast" used effectively.

Firstly, if you’re going to work in Scrum iterations, limiting intake to a given amount of work for the iteration can be a useful way to reduce risk and manage batch size.

This is never, ever how I see sprint commitments or forecasts implemented in the enterprise.

For background, in Scrum, there’s a concept of ‘sprint commitment.’ In a nutshell, the most common way sprint commitment is used by management is to have a team decide how much work to accept into an iteration.

A better way to manage sprint commitments is to frame this commitment not as an agreement to deliver a number of work items but to commit to focusing on an agreed-upon sprint goal or product goal.

I’ll cover first the former, then the latter:

Disclaimer: Legend has it the framers of the Scrumses Guideses realized the word “commitment” was causing some strife and changed the wording to “forecast.” Whether or not this happened, I have literally never encountered anyone really implementing a different way of thinking to commitment. Teams get abused just as hard for failing to deliver a “forecast” as they do for failing to deliver a “commitment,” but I wanted to put this disclaimer in to head off all the CSMs and CSTs who might feel compelled to ‘educate’ me on this mythology.

Sprint Commitment as Promise of Effort

The most popular kind of sprint commitment is where the team gets together in a miserable 4-hour planning meeting and agrees to deliver a subjective amount of ‘work’ in the timebox of the sprint (usually two weeks because of no reason). usually, the team is herded into a room and forced to give made-up numbers to estimate how long each work item will take. Often, this is the first time the team has seen this work they’re estimating, and they’re quite desperate to leave this meeting. To end the meeting quickly, the team finds out what numbers they need to say to reduce any further discussion.

In theory, the team works only on the deliverables they committed to pooping out in the two weeks.

When the team doesn’t deliver everything they were compelled to promise during planning, they have what’s often called “spillover” from one sprint to the next.

I could write a book on all the ridiculous ways this spillover is managed and all the silly consternation that results from said spillover, but that’s not what this piece is about.

Sprint Commitment as Commitment to a Goal

(source: Scrum Guide 2024)

The other kind of sprint commitment is much more useful. It’s the kind I advocated and trained for, and it’s a commitment to set a goal for the sprint and focus efforts only on that goal.

In theory, the team is aware of the product objective of the work they’re doing and can identify an iteration’s worth of experiments or deliverables to best progress toward that goal.

This would mean they don’t work on anything that isn’t part of progressing that goal during the iteration. That means even if something comes up that is part of the product strategy but outside the scope of the committed two-week increment of that goal, the teams don’t work on it.

Product Owner as Single Front Door to the Team

The teams are usually meant to work with a “Product Owner” on all of these things. I could write another book about why the “Product Owner” as usually manifested is a terrible idea, but also, outside the scope of this piece about the bullshittery of sprint commitments. The Product Owner's role is its own specific bullshittery deserving of special attention.

The most useful concept of a product owner is as a single front door to the team. Operationally, the product owner ensures the backlogs for a given iteration remain fixed. Any work that needs to come in must be in service to the sprint goal, and if it’s additive, something else must come out since a team estimated how much they could do, so, adding more work displaces the highest priority agreed-upon work.

What if someone with more positional authority than the Product Owner wants something from the team that’s not part of the sprint goal?

Well, firstly, a cabbage usually has more positional authority than a Product Owner, but unfortunately, it’s usually a Vice President interrupting the sprint.

What’s supposed to happen if the sprint goal has been obviated or rendered obsolete? The Product Owner is meant to terminate the sprint or cancel it.

What this means is the teams immediately stop working toward the sprint goal and enter another miserable four-hour planning meeting (seriously, the guide suggests 2 hours of planning per week of sprint), which makes some sense if we’re working in “committed” iterations and don’t want to waste our time working on stuff that’s not important enough to finish anymore.

(source: Scrum Guide 2024)

I’ve been doing this since 2008, and I’ve never seen a single sprint canceled. The most common calendar-based dysfunction I’ve encountered at nearly every large enterprise has been an insistence on having “synced ceremony cadences,” meaning every team must go through every ceremony at the same time and date.

This sucks in particular for ScrumMasters and Product Owners, who often are responsible for multiple teams and have to fly all over the place, literally and figuratively.

Intake Governance is Essential to Maximizing Flow-efficiency and Predictability

Figuring out what we can get done in a given time can be useful, but not for the reasons leaders often desire.

By ensuring the team is working at a sustainable pace we minimize the cognitive load on their brains thus ensuring they can think more effectively increasing quality of product through quality of life for the brain.

Having a semi-consistent understanding of throughput allows for better decisions to be made sooner regarding investments and capacity growth.

Why it’s Bullshit

Firstly, predicting how many work items can be completed in a period of time is simple. You can easily calculate the average throughput of a team and cut it in half. Then there’s nearly no chance they’ll miss their commitment. You could employ a simple Monte Carlo simulator like the free spreadsheet-based one offered by FocusedObjective that I’ve used to massively predictable success everywhere it hadn’t yet been banned by a cabbage or a VP.

Using statistical methods to forecast throughput capacity not only allows you to model the results of decisions made before the chickens of those decisions come home to roost but they also are a powerful tool for understanding the actual causes of delay or sprint spillover and implement countermeasures.

If predictable delivery was a goal of the leadership they’d never allow work to enter the team and interrupt that committed sprint (goal or volume) but boy howdy does the sprint explode the second a VP decided he wants something else.

Remember, when I say the sprint “explodes,” I don’t mean it’s canceled by the Product Owner, I mean the work committed to in planning ceases to be the commitment, and whatever the positional authority wants just gets jammed in on top of it. Don’t worry. The team still gets beat up for spilling over and “failing” to deliver their commitment. The executives never experience any repudiation for choosing to blow off the process they were previously so very aggressively in favor of forcing the teams to adhere to “by the book” and “to the letter” they’re just fine. In fact often, based on how politically visible, I mean important, the interruption, executives will even actually disband the scrum team or poach the engineers they like the most to form “Tiger Teams” or some silly marshall metaphor “SWAT team” to work on the new whim.

One of my favorite common occurrences is seeing leaders demand a “100% Say:Do ratio” or “100% Commitment: Delivery ratio” without adhering to any of the agreed-upon rules to help teams deliver that to which they were coerced to commit.

One such Director didn’t even bat an eye when the team informed her that they’d committed to 100 points, delivered 110 points, and therefore reported to having been “110% accurate!”

Fundamentally, Scrum is most popular for its more paternalistic interpretations. By forcing teams to promise something, we can flog them when they predictably do not. Usually, the promise was coerced in the first place, and no real data was used to ground the prediction.

Executives who espouse the most strident Scrum beliefs and loudly stamp their feet, demanding teams show maximum “commitment” and “predictability” are often the first ones to abandon all pretense when doing so becomes politically convenient.