# You're two days into a sprint.

A customer reports the integration you shipped last week is breaking their workflow. The Scrum Guide says the backlog is frozen. Reality says you're fixing it. So you do - quietly, and pretend the plan never changed.

This is how most teams handle scope changes - not with a process, but with a fiction.

## The sprint backlog is sacred - and other myths

The Scrum Guide is clear: the sprint backlog is locked once planning is done. In practice, this rule is broken so routinely it barely qualifies as a guideline. Production bugs appear. The CEO walks into standup with a "quick ask." Every team that has run Scrum knows this happens. Most don't talk about it.

The result is a gap between the official plan and actual work - and that gap erodes trust. Retrospectives become performances. Velocity metrics become meaningless.

## Ground Mechanics: the first line of response

In Flights, the first answer to "can we handle this?" isn't to touch the flight at all. [Ground Mechanics](/content/docs/practice/ground-mechanics/index.html) are team members who work between flights - handling bugs, urgent fixes, and requests that don't belong on the main flight plan. When something comes up mid-flight, Ground Mechanics absorbs it without disrupting the crew's focus or adding weight to the flight.

This is the fallback Scrum doesn't have. Instead of quietly amending a frozen backlog, you route the work to the right place.

## When the flight itself needs to change

Sometimes the scope change is too big for Ground Mechanics - it belongs on the flight. In Flights, the captain owns that call. One person looks at the incoming request, looks at the remaining [crates](/content/docs/methodology/crates/index.html), and decides: does this go on the flight, or not?

When a crate is added or dropped, the whole crew sees it. The change is visible and deliberate - not a silent amendment. A fixed landing date keeps the stakes real: when the flight lands, you see exactly what got done.

## The discipline isn't rigidity - it's honesty

A frozen backlog doesn't prevent scope changes - it just makes them invisible. Invisible changes cause the most damage because nobody accounts for them.

Flights takes a different position: scope changes are a feature of how real teams work, not a bug in your process. Ground Mechanics handles the day-to-day interruptions. The captain handles the bigger calls. Everything is visible to the crew and accounted for at [landing](/content/docs/practice/during-the-flight/index.html).

If your team quietly changes the sprint backlog every cycle, you're already doing scope changes - just without visibility or ownership. You might as well make it official.

Read more about [crates](/content/docs/methodology/crates/index.html), [Ground Mechanics](/content/docs/practice/ground-mechanics/index.html), and what happens [during a flight](/content/docs/practice/during-the-flight/index.html) when the plan needs to change.