Running milestones: definitions of done, sign-off and slippage
A milestone that says "UI pass" is not a milestone, it is a hope with a date attached. I have delivered against both kinds, and the difference in how the month goes is not small.
In this article
Open to new projects
Hadjoudj Idris
Game UI/UX Designer
Upwork100% Job Success
Hire me Browse the workThis is written from the supplier's side of the table. I have received a lot of milestone definitions, some excellent and most vague, and the vague ones cost both parties in exactly the same predictable ways. What follows is what the good ones do.
What a milestone is for
- A checkpoint on reality. Not a deadline for its own sake, but a point where the actual state of the project becomes visible to everyone.
- A decision point. Milestones are where scope gets cut, priorities change and problems surface while they are still cheap.
- A payment trigger, when money is involved, which is what makes the definition matter legally as well as practically.
- A shared definition of progress, so that "nearly done" means the same thing to the person building it and the person paying for it.
What the document contains
One page per milestone. If it takes more than a page, the milestone is too big.
| Field | What goes in it |
|---|---|
| Date | One date, and what happens on it: a build, a file drop, a review call |
| Deliverables | A numbered list of things, each of which is either present or absent |
| Definition of done | One line per deliverable, written so two people cannot disagree |
| Out of scope | What is explicitly not in this milestone, which prevents the quiet expansion |
| Dependencies | What the deliverer needs, from whom, and by when |
| Reviewer | One name, with a response window |
| Payment | The amount and the trigger, if applicable |
| Acceptance | What happens if it is rejected, and how many correction rounds are included |
Writing a definition of done
This is the field that does the work, and it is the one most often left as a title. The test is simple: could two reasonable people look at the delivery and disagree about whether it is complete?
| Vague | Done properly |
|---|---|
| UI pass on the inventory | Inventory screen delivered at final quality with empty, full, filtered and error states, annotated for anchors and controller navigation |
| Combat feels good | Three enemy types with telegraphs, hit reactions and damage feedback, playable in the test level at target frame rate |
| Audio implemented | All 42 listed SFX hooked up and audible in game, mixed to the reference level, with the music transition on level load |
| Bug fixing | All bugs at severity A and B closed; C bugs triaged and listed with an owner |
| Localisation ready | All strings externalised, no concatenated sentences, layout verified against the German string set |
Notice what the right column shares: countable things, named states, and a condition that can be checked in a build rather than argued about in a call.
Sign-off: one name and a window
More milestones are damaged by review than by delivery. The two fixes cost nothing and are refused surprisingly often.
- One decision maker, by name. Others comment; one person decides. Four opinions arriving separately over a week is not feedback, it is a queue.
- A response window, agreed in advance. Two working days is normal. Longer is fine if it is stated, because the schedule can absorb a known delay and cannot absorb an unknown one.
- Consolidated feedback, in one document or thread, ordered by importance.
- Feedback on the deliverable, not on things outside the agreed scope. New ideas are welcome and belong in the next milestone.
- Silence is not acceptance, and it should not be treated as rejection either. Write down what happens if the window passes with no response, because it will.
- How to give the feedback itself matters as much as when: the problem, not the pixel.
Payment tied to milestones
- A deposit up front, commonly 25 to 50 percent for contractors, which protects the supplier from the project vanishing.
- Payments against acceptance, not against the calendar, so both sides care about the definition.
- Do not tie a single payment to a milestone that depends on somebody else's work. If the build is late, the supplier cannot deliver and should not be penalised for it.
- Include a correction round in the milestone, and say what a second one costs. Unlimited revisions is not generosity, it is an undefined scope.
- Name a kill fee. If a project is cancelled mid-milestone, what is owed? Deciding this at signature costs one sentence and saves a dispute.
- Beware perverse incentives. Payment on "bugs closed" rewards closing bugs, not fixing them. Tie money to outcomes you actually want.
When it slips
It will. The question is only which of three levers you pull, and pretending there is a fourth is how projects die slowly.
| Lever | When it works | What it costs |
|---|---|---|
| Cut scope | Almost always the right answer | Something you wanted, chosen deliberately |
| Move the date | When the date is genuinely internal | Runway, and every downstream date |
| Add people | Rarely, and only long before the deadline | Onboarding time, usually making it later |
| Reduce quality | Never as a decision, always as a consequence | The thing players will actually notice |
- Declare slippage early. A milestone flagged as at risk two weeks out is a planning problem; the same milestone missed on the day is a trust problem.
- Re-plan the whole chain, not just the slipped item. A milestone that moves pushes everything behind it unless something is cut.
- Do not silently descope. Delivering less without saying so is the single fastest way to end a working relationship.
- Record what caused it. Three milestones in, the pattern is usually one specific dependency or one optimistic estimator, and both are fixable.
The purpose of a milestone is not to prove the team is working. It is to make the truth visible early enough to do something about it.
Milestone anti-patterns
- The mega-milestone. Three months of work with one checkpoint at the end, so problems surface a quarter late.
- The moving definition. Deliverables added during the milestone, so acceptance becomes impossible.
- Review by committee, with no named decision maker.
- Acceptance by silence, where nobody signs off and nobody pays, and the next milestone starts anyway.
- The heroic final milestone, where everything unfinished is stacked into the last month before launch.
- No definition of done for QA, which is how "bug fixing" becomes an infinite phase.
A milestone template
- Milestone: M4, Inventory and shop screens.
- Date: 14 November, build delivered by 18:00.
- Deliverables: inventory screen, item detail, shop screen, purchase confirmation, four shared components.
- Definition of done: each screen at final visual quality, with empty, loading, error and filtered states; annotated for anchors, nine-slice and controller navigation; assets exported and named per the agreed scheme.
- Out of scope: crafting screen, animation polish, localisation of new strings.
- Dependencies: stable build by 1 November; final item list by 25 October.
- Reviewer: one name, responding within two working days.
- Payment: 25 percent on acceptance. One correction round included; further rounds billed at the day rate.
That is one page, it takes twenty minutes to write, and it removes almost every argument a milestone can generate.
How long should a milestone be?
Two to six weeks. Shorter and the overhead of definition and review outweighs the value; longer and problems stay invisible too long. If a milestone needs more than a page to define, it is too big and should be split.
What is a definition of done?
A single line per deliverable stating what must be true for it to be accepted, written so two reasonable people could not disagree. "UI pass on the inventory" is a title; "inventory screen at final quality with empty, full, filtered and error states, annotated for anchors and controller navigation" is a definition.
Should payment be tied to milestones?
Yes, with a deposit up front and payments on acceptance rather than on the calendar. Tie money to outcomes you actually want, never to proxies like bug counts, and avoid tying a payment to a milestone that depends on somebody else delivering a build first.
What happens when a milestone slips?
You cut scope, move the date, or add people, and the third almost never works close to a deadline. Cutting scope is usually correct. What matters more than the choice is declaring it early: a milestone flagged at risk two weeks out is a planning problem, the same one missed on the day is a trust problem.
How many revision rounds should a milestone include?
One is standard for a well-defined deliverable, with further rounds billed. Unlimited revisions sounds generous and is actually an undefined scope, which harms both sides: the supplier cannot price it and the client cannot predict the schedule.
Who should sign off a milestone?
One named person, with an agreed response window, consolidating everyone else's comments. Review by committee is the most common cause of milestone delay, and it is entirely preventable by naming a decision maker before the work starts.
Hadjoudj Idris
Game UI/UX Designer, Remote, worldwide
Need this done properly on your game?
Menus, HUDs, a full UI system, or one screen that isn't working. Tell me what you're building and I'll tell you honestly whether I'm the right fit, and what it would cost.
Upwork100% Job Success
