Scope Creep

The name exists because teams kept landing in the same spot: a schedule slipped and nobody could say where it went. Work estimated at two weeks finished in six, and the retrospective produced no answer, because there was never a day when four weeks appeared at once. Ten or so requests arrived instead, half a day here and two days there, each one introduced with the phrase "this is small."

Any single one of them really is small, and that is what makes the pattern hard to see. If a two-week estimate carries about three days of error, a half-day request fits inside that error and leaves no mark on the schedule. The tenth request disappears the same way, and by then the gap is not measurement error but a factor of three. Measuring the growth means putting the list everyone originally agreed to next to what is actually being built, and few teams run that comparison every week. That comparison is cheap only when the original list was written down somewhere durable.

Having a name changes what can happen mid-flight. "I think we have scope creep here" reads as a request to look at the process rather than an accusation aimed at a person, and the discussion moves from whether to accept the request to what else has to change if it's accepted.

Four steps run in a loop, and the reason the pattern persists is that nothing looks wrong inside a single pass.

1. A small request arrives. Someone walking past the work asks whether the list could also be sortable.
2. There is no ground for saying no. The item isn't on the scope list, but it isn't in the out of scope field either, and anything absent from both lands on whoever is holding the work.
3. It gets absorbed. Half a day isn't big enough to justify reopening a schedule conversation, so the document doesn't change either.
4. The same thing happens again. Eight half-days are four days, and those four days aren't written against any item, so they only become visible once you count them after the date has already slipped.

Growth arrives along three routes, and they are not equally visible. The first is a feature that wasn't there before — an admin issuing screen turning up in work that was about one coupon input field. That one is easy to spot. The second is an existing item growing deeper: the same "validate the coupon code" item now has to handle expired codes, already-used codes, and codes belonging to someone else, which takes the functional requirement from one line to six. The item name never changed, so reading the list shows nothing. This is the route that surfaces last, because it hides behind a name everybody already approved. The third is a quality bar moving, as when a one-second response target becomes 0.3 seconds.

What stops the pattern isn't refusing requests; it is making requests pass through the document. A new one goes into the product backlog — the ordered pile of everything not yet started — and gets ranked against the other items when the next cycle is planned. If it genuinely has to happen now, the scope field gets edited and the date or the staffing gets another look at the same time.

Three situations put this phrase in someone's mouth.

1. The middle of a cycle in flight. When an item nobody committed to slides into a sprint, it gets named at that day's standup. The list agreed to at the start makes the comparison concrete, so anything outside it has to be accepted out loud rather than absorbed.
2. A document review. This pattern is the answer to the question of why the out-of-scope field is worth filling in. Writing down what you won't build isn't there to block a future request; it's there so the conversation about that request ends in five minutes.
3. A retrospective. It's the name used to explain a slip. Counting the added items does more good here than describing them.

All three depend on having something to compare against. When the originally agreed list isn't in a document anywhere, there is no way to claim anything grew, and all anyone is left holding is the fact that the work came in late.

"Was this in the original scope? This feels like creep to me."

Checking whether the work in progress has drifted off the agreed list.

"Each one is small, sure, but that's the fifth this week."

Naming the accumulated total rather than the size of any one request.

"We can take it. But then I'm editing the scope document and re-planning the dates."

Accepting the request while forcing it through the process.

Pagedeck's coupon work ran this way. Mia scheduled two weeks and started. In the first week Sofia asked for a usage history screen on behalf of a customer, and it took half a day, so it was absorbed. In the second week an expiry notification email went in, another day. By the third week, when Theo noticed the coupon validation logic had grown to six separate cases, the work remaining was twice the original list. Nothing in those two weeks had felt like a decision worth remembering.

Counting the added items in that week's retrospective produced nine of them, totaling eleven days. Eight of the nine had come in without ever being written down. Mia switched after that to putting even half-day requests into the backlog first. It wasn't a refusal; it put each request in front of the other items when the next cycle got planned.

The most common move is to treat the requester as the problem. The schedule slipped because of requests from outside, so that reading comes naturally. But the individual requests are usually reasonable — something a customer actually needs, or an error case that can't be dropped. The problem isn't the request, it's the path that lets a request reach the work without reaching the schedule. Point the blame at requesters and the requests don't stop; they route around the meeting and go straight to whoever is building, which removes even the chance of them being written down. What helps is a visible route for requests, not a stricter gatekeeper.

The other frequent mistake is calling any change of scope creep. They are different things. Revising the boundary because of something you learned, and re-planning the dates along with it, is a normal change. The test isn't the size of the request but whether the document and the schedule moved together. A normal change leaves a trace; creep shows up only in the date. Miss that distinction and a team starts treating change itself as failure, which pushes it toward defending a plan everyone already knows is wrong.