Skip to content
← All terms

Glossary

What is scope creep?

The accumulation of unrecorded additions to a commitment's scope — each too small to renegotiate the promise, together large enough to break it.

The working defence is not vigilance; it is a dated out-of-scope list. An in-scope list describes an intention, but the explicit record of what you are NOT doing is what holds when someone asks for one more thing in week six — because the answer changes from "no" to "that was decided, and here is the reason".

Scope creep vs scope change

A scope change is a re-decision on the record: something is added or removed, the commitment is re-baselined, and the reason is written down next to the original. Scope creep is the same addition without any of that — agreed in a thread or a corridor, absorbed into the work, and invisible until the date slips. Additions are not the problem; unrecorded ones are.

Creep is also often a scoping failure rather than growth. The work was always this size, and the original description simply did not mention the edges nobody thought to discuss. No change process can catch a change from a baseline that was never written.

How to prevent scope creep in practice

At commitment, write an out-of-scope list of three to five items — the adjacent things someone will plausibly ask for — each with the reason it is excluded and what would change that. "Not the historical data migration: the new schema lands next quarter and doing it twice costs more than waiting" is an exclusion that will hold; "out of scope: migration" is not.

When a request arrives mid-delivery, check it against the list. If it is listed, the conversation becomes "we decided not to do this, for this reason — has the reason changed?" If it is not listed, it is a new decision: size it, name what it displaces, and if it goes in, record the change as a re-baseline with the original kept alongside.

Common mistakes

Treating creep as a discipline problem and asking people to say no more often; without a written baseline there is nothing to say no from. Writing an exhaustive exclusion list — if a demand needs thirty exclusions, it is too big and should be split. And absorbing small additions because each one is "only a day": the whole definition of scope creep is that every single addition was too small to renegotiate.

Related terms

  • Commitment exception — A recorded justification required to commit to work that is not yet decision-ready, naming why it is early, what is still unknown, who accepts the risk, and what condition would change the decision.
  • Delivery governance — The practice of deciding what to commit to — establishing value, ownership, capacity, dependencies and open questions before people, budget or a date are promised.
  • Decision-ready demand — A demand that can responsibly be committed to: the problem stated apart from the proposed solution, an intended outcome, a named owner, a first capacity figure, the dependencies, and the open questions written down as unknowns.

This definition comes from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.

$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.