The Scope Crept Back In Anyway. That Was Never a Discipline Problem.

The Scope Crept Back In Anyway. That Was Never a Discipline Problem.

A month after my team built an explicit working agreement defining how our roadmap and our sprints were supposed to interact, I sat down to review the sprint calendar for a June release: a professional standalone version of our team's medical encoder. The working agreement named decision rights, sprint ownership standards, and meeting criteria, all confirmed and documented. What I found was scope that had crept back in anyway, sprint by sprint, each addition small enough on its own to seem manageable, until development wasn't going to wrap until the week before release.

This release mattered to me beyond the calendar. It was the test of whether the operating system I'd spent months installing on this team actually held: whether people would act on the authority we'd explicitly given them to question and push back, or whether commitments would still quietly erode the moment nobody was watching closely. So I went through everything added since March, one item at a time, and asked a single question: is this truly MVP for this release? Most of it wasn't, and features moved out, some as far as October.

What I felt afterward wasn't disappointment. It was relief, because the drift matched exactly the pattern I expected. That's an uncomfortable thing to admit: some part of me already knew that naming a boundary once, even successfully, doesn't install it. The relief was recognition, not surprise.

The standard advice for product-engineering friction treats this as a communication problem. Get the two sides more aligned: more syncs, shared roadmap tools, backlog grooming built around empathy. When scope creeps back in, the standard diagnosis is a discipline failure: the PM keeps asking for too much, or engineering isn't pushing back hard enough. Fix the people, the thinking goes, and the drift stops.

That advice relies on personalities, not systems, and personalities change. The moment the specific person willing to have the hard conversation moves on, whether that's a PM who learns better discipline or an engineering lead who's willing to say no, the system has nothing left to fall back on. What's missing is explicit Decision Boundaries: who owns the call on what counts as MVP, under what conditions, and what triggers escalation before scope gets added. Without them, the boundary lives in one person's judgment and their willingness to repeat an uncomfortable conversation, not in the system itself.

That's what my own June release actually proved. The scope crept back in the same way it always does, not because anyone was less disciplined that round, but because nobody had defined, as a standing rule independent of who's in the room, what counted as MVP and what triggered a real trade-off conversation before something new was added. I personally enforced it that time, going item by item, and it worked. But that's still a personality-dependent fix: it worked because I was the one applying the pressure.

Here's the cost of that kind of fix. It holds exactly as long as the enforcer is present and paying attention, and it resets the moment they're not, whether from a promotion, a reorg, or simply a release where nobody has the bandwidth to go through every item by hand. The leaders who get this right aren't the ones with the most disciplined product managers or the most assertive engineers. They're the ones willing to write the rule down before the pressure arrives, so the boundary doesn't depend on who's paying attention that week.

Communication and cadence have to be fully architected, not just practiced, and decision rights have to be documented, not just understood. That means defining, in writing, before the next release cycle starts, exactly what counts as MVP and exactly what triggers a trade-off conversation before scope gets added. Done that way, the boundary catches the drift automatically, instead of requiring someone to notice it and relitigate it after the fact.

Ask yourself one question about your own last release: when was the last time a commitment truly held, where the MVP you determined at the start was the MVP you actually shipped, without anyone having to go back through the list and defend it after the fact? If you can't answer that quickly, the boundary you're relying on lives in a person, not in your system, and it will drift the next time that person is stretched too thin to catch it again.

I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS™ :http://TheLeadershipOSBook.com