On the third “yes” in a sprint, something has to give.
The first ask sounds reasonable. The second is a stretch. By the third, you’re staring down a quiet decision: which of the previous two will you break, and how will you tell the people who asked?
It is rarely the first request that breaks a sprint. The first request lands inside the budget you imagined for yourself when you wrote the plan, and you accept it the way you might accept a small favor from a colleague — a little inconvenient, but the kind of inconvenience that working together involves. The second request lands a few days later. By then the budget you imagined is already smaller than you remembered, but you can still see the shape of the original plan if you squint, and so you absorb the second request the way you absorbed the first, and you tell yourself that you will simply move faster.
The third request is the one that demands a decision. By now the budget you imagined is gone, and the original plan has been replaced by a plan in which everything fits only if nothing goes wrong, and in your experience something always goes wrong. You have three options, and exactly one of them does not involve telling someone they cannot have what they asked for. That option, the option in which you simply work harder, is the one most engineers reach for first — and it is the option that, six weeks later, produces the conversation in which you explain to your manager why three things shipped late instead of one thing on time.
What follows is a field guide for the moment when scope outruns capacity. It is written for the engineer who has already said yes twice and is staring at the third ask. It is also written, indirectly, for the manager who keeps wondering why their team’s estimates have started drifting and why the senior engineer who used to ship reliably has begun to seem quietly resentful.