Key takeaways
- Write a cut line before sprinting, not during panic
- Change requests need tradeoffs - time, cost, or scope elsewhere
- Protect the milestone definition of done in writing
Every “quick add” feels free in a meeting. In the codebase it’s a new edge case, QA path, and support script. Scope creep wins when there’s no agreed way to say no without drama.
Install kill switches early
- 01
Milestone “done” statement
One paragraph: who can do what when this milestone ships. Anything outside waits.
- 02
Cut line
Ranked backlog with an explicit line. Below the line is not “maybe” - it’s next milestone.
- 03
Change trade
New request must name what drops, what slips, or what budget increases.
Creep pattern
Kill switch
“While you’re in there…”
Logged as next-milestone, not this PR
Design polish mid-build
UX debt list with scheduled pass
Stakeholder drive-by
Single decision owner per milestone
Infinite edge cases
Documented out-of-scope behaviors
“If everything is priority one, you don’t have a plan - you have anxiety.”
- Written milestone done statement shared with stakeholders
- Ranked backlog with a visible cut line
- Change-request template: add / drop / slip
- One decision owner who can break ties
1
Decision owner per milestone
3
Trade levers: drop, slip, or fund
Weekly
Parking-lot review cadence
