Guide

Schedules die from late discoveries. Pull risk forward. Milestones should be shippable slices, not layers ("finish all backend, then all frontend").

Concept

De-risking means you spend the first days on the work most likely to change the plan. A milestone is a slice a user (or an internal dogfood user) can touch.

Walking through risky work first

  1. Prototype the scary integration on day one or two — the vendor SDK, the dual-write, the permission model that might not exist.
  2. Prove the critical path end to end with stubs rather than polishing the easy UI first.
  3. Time-box and decide: if the spike fails, change the plan this week, not the week before launch.

Building the UI first feels like progress and hides the landmine. Building the payment reconciliation spike first feels slower and saves the project.

Milestones that deliver user value

Prefer:

  1. Internal-only export behind a flag for one report type.
  2. Same export for all report types.
  3. Scheduled email delivery.
  4. Self-serve UI.

Each milestone can roll back, demo, and teach you something about the next estimate. Basecamp's Shape Up pushes the same idea with appetites (time budgets) instead of endless backlogs: fix the time, flex the scope.

Back to the folders date. Answer to the PM: "Folders with inherited group ACLs: I can commit to internal dogfood by the 21st and external by the 28th if we cut 'share folder with arbitrary email' from v1 — that needs a separate invite flow (~1 week more). If email-share is required for the 28th, we slip external to the 5th or drop something else."

That conversation is estimation doing its real job: turning a date into a scope negotiation.

Trade-off

Fixed scope / flexible date vs fixed date / flexible scope. If the date is real (conference, compliance), cut the slice. Fixed scope and fixed date with no buffer is how teams burn out and still miss.

Common mistakes

  • Starting the easy work first.
  • Milestones that are layers ("backend done") instead of slices a user can touch.
  • Treating the first plan as sacred after a spike changes the design.

Check yourself

You have a pretty admin UI to build and a vendor payments API you have never called. What do you schedule first?

A time-boxed spike on the payments API. The UI cannot save a late discovery there.

Leadership needs a date. Email-share of folders is extra. What do you offer?

Internal dogfood on the original date; cut email-share from v1, or slip external.

Key takeaways

  • Schedule the riskiest work first; change the plan this week if the spike fails.
  • Milestones are shippable slices, not architectural layers.
  • A date plus extra scope is a negotiation, not a dare.
  • Shape Up's move: fix the time, flex the scope.

Further learning

Next, calibrate yourself with history: evidence-based scheduling.

Shape Up (Basecamp)Shape Up will help you break free of “best practices” that aren’t really working, think deeper about the right problems, and start shipping meaningful projects your team can celebrate.basecamp.com