How do you handle scope creep on a real project?
Scope creep stops with one mechanism: every new request must change scope, deadline or budget — and the choice is made explicitly, in writing, before the task enters the backlog.
Scope creep does not come from "bad stakeholders". It comes from the absence of a change-request process. The request lands in a chat message, the PM says "we will see, maybe it fits", the task is added to the backlog without removing anything else, and the deadline stays the same. Three months later the team is working on twice the original scope with the same budget and no one can tell when it happened.
1. The firm triangle: scope, time, budget
Classic project management: you can change two sides of the triangle, never all three. Want to add scope? Either drop some scope, or move the deadline, or grow the budget. This is not up for debate — it is a law of delivery.
The stakeholder meeting then becomes very simple: "We want this too." → "OK, which scope drops to make room? Or how far do we move the deadline? Or how much budget do we add?" Stakeholders understand the trade-off when it is put in these terms — it only becomes vague when the PM avoids the question.
2. Written change requests, not chat messages
Any scope-changing request (no matter how "small") goes through a Change Request. A short form: what is asked, why, what gets dropped in exchange, impact on the deadline, decision. The CR is approved in writing by the stakeholder before the task enters the active backlog.
That alone filters 60-70% of requests — the stakeholder who has to write a paragraph realises they do not really need it. The rest enter the backlog informed, with consciously accepted trade-offs, not smuggled in. The tool must surface CRs in portfolio view so they do not get lost.
3. Sprint Lock: no scope changes mid-sprint
In Scrum, once a sprint starts it does not take on new scope. A request that arrives on day 4 does not enter the current sprint — it goes into the backlog for the next sprint, evaluated at planning. A simple rule, but often broken under pressure.
For Kanban teams (continuous flow), the equivalent is the WIP limit: if the "In Progress" column is full, the new task waits in "To Do" — no jumping the queue. That protects the speed of the existing flow.
4. 15-20% buffer, not "we will see when it lands"
There will always be urgent requests that truly have to land — critical bug at a big customer, a regulator question. You absorb them with the planned buffer (15-20% of capacity), not by adding them on top of the plan.
If a sprint burns all the buffer on stakeholder urgencies, flag it at review: "The sprint was dominated by unplanned urgencies, planned scope shipped at 70%." That triggers a productive conversation with management — not a quiet cover-up.
5. Weekly scope-vs-baseline report
Keep a baseline of original scope vs current scope. The weekly status report includes "scope drift": how much it grew, what was added, what was removed. Visibility creates accountability.
When the stakeholder sees in the weekly report that scope grew 35% in 6 weeks while the deadline did not move, the conversation changes. Before: "Why are we late?". Now: "OK, we move the deadline or we cut." Numbers resolve political conversations.
Block scope creep in 4myprojects
See in black and white what enters the sprint after kickoff: new tasks land in the activity log, the burndown shows how far scope has grown since day one, and the insights page drops the health score and raises the risk level when the backlog grows or the sprint falls behind — no PM as a political buffer.