Scope is a budget, not a wish list
A feature list is an opening position, not a plan. Holding the date and spending scope against it turns every new request into a trade instead of an argument.
Every project starts with a list of everything the client wants. That list is never the plan — it is the opening position. The plan is what survives contact with a date, and treating scope as a budget rather than a wish list is what makes the date hold.
Fix the date, negotiate the contents
A deadline that moves teaches everyone that deadlines move. We hold the date and spend scope against it, which turns every new request into a trade rather than an argument.
You can have it, but something else leaves the release. Which one?
Three questions before anything is added
What does this replace in the current release?
What breaks if it ships a month later?
Who notices on day one if it never ships at all?
Most requests do not survive the third question, and the ones that do are usually worth re-planning around.
Scope conversations go better standing at a whiteboard than sitting in a document.
What we track
Three numbers per project. Everything else is reporting for its own sake.
SignalTargetWhat it tells usScope added after kickoff< 15%The brief was understoodDates moved0 per releaseEstimates are honestCut lateTracked, not hiddenTrades were made deliberately
Keeping it visible
The budget lives in the repository next to the code, so it is reviewed in the same place the work happens. A single npm run scope prints the current state:
npm run scope -- --release 2026.10
git log --oneline --since="last monday" | wc -lNone of this is clever. It is the same conversation every week, written down, with the trade made explicit instead of discovered in the last sprint. More on how we run those weeks in predictable delivery.