Stephen Brenish
You’re three weeks out from a major milestone review. Your studio lead asks for the deliverable document. You panic slightly because you realize you’ve never actually written a formal one, and you’re not sure what should go in it. You’ve got spreadsheets, meeting notes, and a general sense of what’s been completed, but there’s no single source of truth. Sound familiar?
Most producers learn this the hard way. A milestone deliverable document isn’t just a checkbox for your publisher or studio leadership. It’s your contract with the team about what “done” actually means, your defense against scope creep, and your historical record for postmortems. Done wrong, it becomes a bureaucratic nightmare that delays shipping. Done right, it eliminates arguments and keeps everyone aligned.
What Goes Into a Milestone Deliverable Document
A solid milestone deliverable document has four core sections: the executive summary, the scope definition, the acceptance criteria, and the known issues or deferred work. This structure scales from small indie teams to 200-person studios.
The executive summary should be genuinely brief. Maybe 150 to 250 words. State what milestone you’re completing, when it’s due, which teams are responsible, and the high-level deliverables. This is what your studio director reads before a meeting. Be specific about dates. “End of Q3” is vague. “September 28” is clear.
The scope section is where you detail exactly what’s included in this milestone. That means every feature, system, and piece of content that’s supposed to be done. If you’re hitting an alpha milestone for a 30-hour RPG, list the opening act completely, name the playable characters, note how many dungeons are included. Break it down by discipline: art deliverables separate from code, audio separate from narrative. You’re aiming for a level of detail that someone who wasn’t in every meeting can understand what the milestone contains.
Here’s where you also document what’s explicitly not included. That feature your lead wanted? If it’s punted to beta, write it down here. That boss battle you cut? Document it. Deferred work is still work, and it should be visible in your milestone document. Otherwise, people assume it’s coming and you end up defending decisions in the final week before launch.
Acceptance Criteria: The Muscle of the Document
Acceptance criteria are measurable, testable conditions that prove the milestone is actually done. Not “the story is interesting” but “all five main quests have dialogue recorded and implemented, all dialogue is subtitled in English and Spanish, and quest markers function correctly on the map.”
For a multiplayer shooter hitting a network stability milestone, your criteria might include: “Matchmaking times under 60 seconds with 100+ simultaneous players,” “Server uptime measured at 99.5% over a 7-day stress test,” and “No player disconnections after 30 minutes of continuous gameplay.” These are testable. You can prove them.
Break criteria into categories. Functionality criteria address whether features work. Performance criteria establish frame rate targets, load time maximums, or memory footprints. Polish criteria define animation completeness, UI responsiveness, and visual polish levels. Quality assurance criteria specify which platforms have been tested and what bug severity threshold must be met.
A real example: if your milestone includes controller support, don’t just write “controller support implemented.” Write: “All gameplay, menu navigation, and cutscene skipping functional with standard Xbox and PlayStation controllers. All on-screen button prompts reflect the controller in use. No gamepad input drops on any of three test units during 2-hour play sessions.” That’s testable and defensible.
Technical and Production Documentation
Your milestone deliverable document should include a dependencies section. What does this milestone depend on that’s not yet finished? If your animation pipeline needs a specific tool update to deliver character animations on time, that’s a dependency. If your audio team needs final dialog from the narrative lead two weeks before the milestone, that’s a dependency. Call these out explicitly.
Include a version control snapshot or build information. If your game is built from source, record the specific commit hash or tag. If you’re delivering from a particular build server, note that. Six months later when someone asks “what exactly was in that alpha build we showed at the conference,” you need a way to recreate it.
Document any known issues that didn’t make the cut-off. This might sound counterintuitive, but it’s essential. If there’s a memory leak in the shader compiler on AMD cards but you’re hitting the milestone anyway, write it down. You’re not hiding it. You’re being transparent that this is a known issue being addressed post-milestone.
Capture the test matrix: which platforms, which configurations, which devices have you actually validated the milestone on? “Tested on Windows 10 and 11, Intel Core i7 8700K and newer, RTX 2080 and newer, with DirectX 12” is factually useful. “Fully tested” is not. Testing rigor ties directly to your crunch patterns, so this section is worth the detail.
Who Signs Off and How
Your milestone deliverable document needs a sign-off section. Who’s responsible for confirming that acceptance criteria have been met? Usually this is a lead engineer, art director, and project lead together. You might also need sign-off from a QA lead if your studio has separate QA management.
This matters because it prevents the nightmare scenario where, three weeks after the milestone, someone says the work doesn’t actually meet the original criteria. By requiring sign-off during milestone review, you’ve got documented confirmation that the lead engineer agreed to those criteria, tested them, and confirmed they passed.
The sign-off should include initials, dates, and optionally a one-line statement of any caveats. “Approved, with note that shader performance optimizations are ongoing but frame rate targets met on specified hardware” is valuable context. It prevents people from assuming the work is 100% done when there’s active optimization work happening.
Creating a Template That Scales
The best milestone deliverable document is one you can reuse. Build a template with sections that work for every milestone your studio hits. The structure stays the same. The content changes, but the format remains familiar.
Here’s a practical structure you can adapt:
- Milestone Header (name, date, owner, status)
- Executive Summary (2-3 sentences, high-level scope)
- Scope by Discipline (Design, Engineering, Art, Audio, QA, etc.)
- Features and Systems Included (detailed list)
- Explicitly Deferred Work (what’s not in this milestone)
- Acceptance Criteria by Category (functionality, performance, polish, QA)
- Dependencies and Blockers (what could still break this)
- Build Information (commit hash, platforms tested)
- Known Issues (transparency, not excuses)
- Approvals Section (sign-offs with dates)
Use a shared document format that your studio can access. A Google Doc, Confluence page, or Wiki page that’s linked from your project management tool. If it’s buried in Slack or email, it won’t be found when you need it.
The principles of agile game development include regular inspection of deliverables, and your milestone document is that inspection checkpoint. It forces clarity. It prevents assumptions.
Milestone Deliverable Document Checklist
Before you send a milestone document for review, run through this checklist:
Clarity Check: Can someone unfamiliar with your daily standups understand what’s included just from reading the scope section? If not, add more detail.
Testability Check: For each acceptance criterion, ask: can we measure this? Can we prove it? If the answer is maybe, rewrite it.
Completeness Check: Is every feature mentioned in sprint planning actually listed in the scope section? Have you called out what isn’t included?
Sign-Off Readiness Check: Have the actual leads (engineer, artist, QA) reviewed the criteria they’ll be signing off on? Do they think the targets are realistic? If they’re surprised by the criteria, revise before milestone.
Timeline Check: Is there a clear date and deadline? Are dependencies flagged with enough lead time?
Assumption Check: What are you assuming will go smoothly? Write down the three biggest risks and how you’re mitigating them.
FAQ
Q: How detailed should acceptance criteria actually be?
A: Detailed enough that someone who wasn’t in your design meetings can understand what passes and what fails. Three bullet points and you’re being too vague. Fifty bullet points and you’re over-specifying. Aim for the sweet spot where criteria are specific enough to be testable but broad enough that you’re not getting bogged down in implementation details.
Q: Should I include art asset counts and exact feature lists in the deliverable document?
A: Yes, if those numbers matter to your timeline or your platform constraints. “40 unique enemy types implemented and animated” is more useful than “all enemy types ready.” “Exactly 127 art assets under 2MB each” might be overkill unless you’re hitting a specific memory budget. Include numbers that affect decisions.
Q: What if we miss the milestone? Do we rewrite the whole document?
A: No. You update it to reflect what actually shipped and what slipped. Mark the new delivery date, move deferred work to the next milestone document, and document why the slip happened. This becomes your record of what went wrong, which is invaluable for postmortems.
Q: How do I handle acceptance criteria for subjective things like “polish”?
A: Make them as objective as possible. Instead of “the menu looks polished,” write “all menu buttons have hover states, all text is kerned and fits within UI bounds on 1080p and 4K, and menu transitions complete in under 300ms.” You’re moving from subjective to measurable.
Q: Do I need a separate milestone deliverable document for each milestone, or is one master document enough?
A: One master document that you update for each milestone is fine for small teams. For larger studios with multiple simultaneous milestones or external parties (publishers, certification boards), separate documents per milestone prevent confusion. Each milestone should be its own document that you can reference independently.
Closing Thoughts
A milestone deliverable document is one of the highest-leverage documents you’ll write as a producer. It’s the bridge between intention and reality. It prevents the week-before-shipping panic where someone suddenly asks, “Wait, we said we were shipping online co-op in this version, right?” and you have to argue about it instead of building it.
The time you invest in writing a clear, detailed milestone document at the start of a milestone saves you ten times that in arguments, rework, and miscommunication later. It’s not bureaucracy. It’s clarity. And clarity is what keeps projects moving.
