Managing Sprint Scope Creep - Protecting Sprint Commitment
Stakeholders keep adding "small quick wins" mid-sprint. What started as 40 points becomes 55+ by sprint end. We never hit our commitment. How do you say no politely while maintaining flexibility for genuinely urgent work?
Trade-off policy works brilliantly: Accept new work only if equal points are removed. Stakeholder wants urgent 5pt fix? Ask which planned 5pt story to drop.
This forces prioritization conversation instead of infinite capacity assumption. Make it visual: Sprint board shows "40/40 points committed" and new request requires removal. Suddenly "urgent" requests become "can wait until next sprint."
Create explicit interrupt budget: Reserve 10% capacity for unplanned work. We plan 36pts in a 40pt sprint, keep 4pts buffer for stakeholder emergencies.
Buffer is visible in sprint planning - stakeholders see it exists. When buffer is full (4pts consumed), they see consequences of interrupts. Self-regulation happens naturally when cost is visible.
Kanban-style WIP limits saved us. Sprint board has "In Progress" column limited to 8 stories. New work physically can't start until something finishes and moves to Done.
Physical constraint stops scope creep better than policy. Stakeholders see full board at standup, viscerally understand team is at capacity. No need to argue - the board speaks.
Document everything added mid-sprint in visible "scope additions" log. Sprint review slide: "Original commitment: 40pts. Mid-sprint additions: 15pts. Total attempted: 55pts. Completed: 42pts."
Pattern becomes impossible to ignore. After 3 sprints of this data, stakeholders stopped adding work because they saw the velocity impact. Data changes behavior when blame doesn't.