milestone

A dated yes-or-no checkpoint where someone decides to go on, change course or stop; it takes no time itself. It is most useful when it is tied to a decision and a named decider, not just to an event being done.

A milestone is a point in the schedule with no duration of its own, marking that something important is done. The work that leads to it sits in the tasks before it; the milestone itself takes zero days.

Its real use is as a decision point. Write each milestone as a yes-or-no question with a date ("by 25 December, do we have 8 tutors who passed a demo lesson?"), say how the answer will be checked, and prepare the decision for "no" in advance. A prepared decision takes the sponsor a day; one improvised on the day takes a week, and the week is usually what the project doesn't have.

Put milestones where chains of waiting work meet: the points where several later tasks depend on something being finished. A useful test: if nothing waits for it and nobody decides anything there, it is a task on someone's board, not a milestone. "Kick-off held" and "design done" usually fail that test.

When a milestone comes back "no", the project lead tells the decider the same day, in writing: the question, the answer, the prepared decision and what it costs. Milestones survive in short-iteration planning too: they become the fixed checkpoints, often on an iteration's last day, while the work between them is planned week by week.

Example

Milestones of Klasna's physics launch, on a schedule counted in working days from Monday 2 November 2026 (day 22 = 1 December, day 32 = 15 December, day 40 = 25 December):

Date	Question	If the answer is "no"
1 December (day 22)	Are all five curriculum units drafted, so Vira's review can end by 15 December?	Vira starts the review with the finished units that day; the late author gets a fixed date within the week; if 15 December is then at risk, Leo hears the same day what moves and what could be cut
25 December (day 40)	Do we have 8 tutors who passed a demo lesson?	Prepared option: open with six good tutors and cap the number of learners. It changes a success criterion, so it goes to Leo in writing
Before 1 February	Go or no-go: are all acceptance criteria met?	Fix, cut, or accept with an exception Leo signs

The 25 December milestone comes from a hidden chain: tutor onboarding waits for demo lessons, demo lessons wait for the final curriculum, and the curriculum is final only after Vira's review on 15 December. The review runs to day 32 and the demo lessons take 8 days, ending on day 40. Roman's first plan, onboarding in the first week of December, could not work, and the milestone makes that visible in November.

"Landing page design done" was proposed too. Nothing waits for the design alone and nobody decides anything there, so it stayed a task on the platform lead's board.

Common mistakes

Milestones that decide nothing. "Kick-off held" or "design done" are events or tasks; nothing waits for them.
Giving a milestone a duration. The work goes in the tasks before it; the milestone is a point.
No prepared decision for "no". Then the missed milestone turns into a week of meetings.
Waiting for the weekly status to report a miss. Tell the decider the same day, in writing.
Dropping milestones when work goes iterative. Keep a few as fixed checkpoints between the weekly plans.

Learn it in the course

Dependencies and milestones as decision points · Find what waits for what, including the dependency nobody wrote down, and turn milestones into questions with a decision ready for each answer.
A fixed date with weekly iterations · Keep the exam date and a few milestones fixed, let scope flex, and run the last weeks in short iterations with a board, limits on work in progress and a weekly demo of working pieces.