Planning milestones that can be verified

The word is used for four different things, and only one of them is a milestone.

The distinction matters because only a milestone can be passed or missed observably. "We are in the implementation phase" cannot be false. "Attendance recording is archived, and the two scenarios ran in front of the client" is true or it is not, and everybody in the room can tell which.

A milestone is therefore not a celebration and not a report. It is a question with a yes-or-no answer, agreed in advance.

The formula is short: by <date>, <observable condition> is true, checkable by <who> through <how>.

Three properties are worth naming in the right-hand column. Each has an observer who is not the team — self-certification is how milestones become ceremonies. Each names a mechanism, so nobody has to invent the check on the day. And each is written in terms of behaviour of the system, not of activity of the team, which is why they survive a change of plan.

The strongest possible criterion is one a machine evaluates: "the pipeline is green on `main`" needs no meeting at all. Use it wherever it fits — but do not force it, because the interesting milestones involve a person watching the software do something.

Milestones are not evenly spaced. They go where the uncertainty is, because their job is to convert an unknown into a known while the answer still leaves options.

Two placement rules carry most of the value.

Put the first thin end-to-end slice early. One capability, from the user interface through to the database and deployed, tells you more about the risk in the project than three capabilities that all stop at the service layer. The integration problems — the deployment, the authentication, the machine nobody has access to — are the ones that turn into three lost weeks, and they surface only when something is joined up.

Leave a milestone between "feature complete" and the deadline. If the last milestone is the deadline, a slip discovered there has no answer. One four weeks earlier can still be answered by cutting scope, which is a decision somebody is allowed to make.

A status report says where you are. A milestone trend chart says how your estimate of the finish has been moving, which is the more useful of the two.

The chart makes one thing visible that no single report can: a systematic slip. Every individual delay has a good reason, and each one alone sounds like bad luck. Three in a row moving in the same direction is not luck — it is a rate, and a rate can be extrapolated.

The honest use of it is to raise a scope conversation early. The dishonest use is to leave the date where it is and hope, which is how "we are on track" is truthfully said every week until the last one.

Missing one is ordinary. What is measured is what happens next, and there are exactly four legitimate responses:

What is not a response: working more hours and saying nothing. It is unverifiable, it does not survive contact with February, and it removes the one thing the milestone was for — telling somebody else, early, that a decision is needed.