← All notes
Project Scoping7 min

A fixed date is not a fixed scope

Some dates are real constraints — a trade-show booth, a Valentine print window, an App Store submission that has to clear review. Treating the date and the full feature list as both fixed is how testing, refusal paths, and the risky seam get dropped in the last two weeks without anyone writing it down. We treat a fixed date as a reason to decide what flexes: scope, not the integrity of what ships.

Hard dates are real; dual-fixed plans are not

A florist that prints delivery tickets in the workroom cannot invent calendar days in mid-February. A medical device site that has to be live for a conference cannot ask the venue to wait. Endeo builds that need a TestFlight build in reviewers' hands before a demo have a clock that does not care how many tickets remain. Those dates are constraints, not preferences.

What fails is keeping the date hard and also treating every item from the workshop backlog as equally hard. The plan looks decisive on paper. In week six the seam spike is late, the OCR refusal path is unfinished, and the team quietly skips device passes so the screens still demo. Nobody signed that cut. The date absorbed it.

So when a date is non-negotiable, we say so in the scoping notes, and we also say which variable is allowed to move. If neither date nor scope can move, the only remaining flex is quality — and quality is the one we refuse to leave unnamed.

Write the cut list before anyone estimates

A cut list is not a vague 'nice to have' column. It is an ordered list of outcomes that can leave the first ship without breaking the reason the date exists. Each row names what drops, what still has to be true for the date to count as met, and who owns the call to pull it.

We write it during scoping, not during crunch. For Al's Flowers that might mean the first window ships order ingest, ticket generation, and reprint-vs-void on the operational record, while a later gift-message surface waits. For a Sanity marketing site it might mean the clinician resource library ships and the secondary campaign landing waits. The point is the same: the date owns a minimum coherent product, and everything else is ranked against that minimum.

If the team cannot name three things that could leave without killing the date, the date is not a constraint yet — it is a wish wearing a calendar. Either soften the date or shrink the ambition until a real cut list appears.

Same-size swaps, not silent drops

Mid-build, new asks still arrive. A fixed date does not freeze learning; it freezes the habit of adding without removing. The rule we write into the scope is swap-for-swap: a new outcome of roughly the same size can enter only if something of the same size leaves the cut list or the build list, with the trade written the same day.

That pairs with how we already classify asks — clarification, trade, or change — but the date adds a fourth pressure: time. Without an explicit swap rule, 'we'll squeeze it in' becomes the default, and the squeeze lands on the seam spike, the recovery path, or the device session that was supposed to prove the build works under load.

Silent drops are worse than written cuts. A written cut can be restored after the date. A silent drop usually means the acceptance criteria never mentioned the thing, so nobody notices it is gone until production does.

Done for the date vs done for the product

Two finish lines share one project. Done for the date means the minimum coherent product works under the operating conditions the date cares about — real webhooks, real printers, real devices, refusal paths that do not invent data. Done for the product means the remaining ranked outcomes, polish, and follow-on surfaces that the cut list parked.

Mixing those two finish lines is how a demo gets mistaken for a ship. We keep them separate in the scoping notes: acceptance for the date, and a short post-date queue with owners. The post-date queue is not a parking lot that evaporates; it is scheduled work with a revisit date, same discipline we use for deferred decisions elsewhere.

If something is required for the date to be honest — symbolicated crash reporting on TestFlight, idempotent order ingest, a CMS fallback that does not blank a page — it does not belong on the cut list. Cuts remove ambition. They do not remove the conditions that make the shipped slice trustworthy.

What we put in the scoping notes now

When a stakeholder names a hard date, we capture five lines before the estimate hardens: the date and why it is hard; the minimum coherent product for that date; an ordered cut list with owners; the swap rule for mid-build asks; and the split between done-for-the-date acceptance and the post-date queue.

Those lines do not make the calendar softer. They make the tradeoffs visible while there is still room to choose. A fixed date without a cut list is a plan that will invent its cuts later, usually in the places that were never demoed.

Questions

What if nothing can be cut and the date cannot move?
Then quality is the unnamed flex — skipped tests, unfinished refusal paths, unspiked seams. We refuse to leave that unnamed. Either shrink the minimum coherent product until a real cut list exists, or move the date. Dual-fixed plans fail by silently deleting integrity.
How is a cut list different from a nice-to-have column?
A cut list is ordered, owned, and tied to what must still be true for the date to count as met. Each row is something that can leave the first ship without breaking the reason the date exists. A vague nice-to-have column usually becomes 'everything is still in' until crunch invents the cuts.
Can we still add work after the build starts?
Yes, under a written swap rule: a new outcome enters only if something of similar size leaves the build or cut list the same day. That keeps learning possible without letting the date absorb unbounded adds by skipping seams and recovery paths.

Sources

  1. Scrum.org — Dealing with fixed date, fixed budget work — Scope as the flex variable; same-size backlog swaps when date and capacity are hard.
  2. Jeff Gothelf — Fixed time, fixed scope projects — Dual-fixed plans fail into slipped dates, silent cuts, or crunch that burns the team.
  3. Related Fathom note — A clarification is not a change request — Mid-build asks still need clarification / trade / change labels; the date adds the swap pressure.

Have something to build?

Tell us what you're working on and we'll tell you honestly whether we're the right fit.

Work with us