Summary
The Minimum Viable Game (MVG) is the smallest version of a game that delivers the core player experience — the game that must ship for the project to be considered successful. It is the Agile adaptation of the Minimum Viable Product concept applied to game development.
Defining the MVG early does two things: it identifies the features that are truly non-negotiable, and it makes everything else explicitly optional — additional value that can be cut to protect the ship date without destroying the product.
Key ideas
Why scope management is different in games
Games have a unique scoping problem: the fun only becomes visible through play. Features that look essential in a design document may turn out to be unnecessary once the game is playable; features that seemed optional may turn out to be critical to the experience. This means scope cannot be locked at the start of a project — it must be managed continuously.
The MVG is not defined once and frozen. It evolves Sprint-by-Sprint as the team learns more about what makes the game worth playing.
MVG vs. the traditional design document approach
Traditional approach: specify all features up front; cut at the end when time runs out; ship whatever remains. This produces:
- Late-stage cut decisions made under deadline pressure, without good information
- Features cut because they are “90% done” rather than because they lack value
- A shipped game that is a shadow of the original vision rather than the best possible game within constraints
MVG approach: define the smallest game that is worth shipping first; add features on top in value order. This produces:
- Explicit, value-ordered cuts made early, with good information
- A ship date that is protected by the MVG floor
- Additional features treated as upside rather than debt
The MVG and development stages
Keith describes four development stages that the MVG concept structures:
| Stage | Goal | Agile mechanism |
|---|---|---|
| Pre-production / Exploration | Prove the core mechanic is fun | Risk-first sprints; prototype stories |
| Production | Build the MVG reliably | Sprint backlog; velocity-based forecasting |
| Hardening | Stabilise, optimise, polish | Dedicated hardening sprints; QA integration |
| Launch | Ship | Final marketing/demo sprint |
The MVG is established by the end of pre-production. Everything in production is building toward it. Features beyond the MVG are queued in the backlog and pulled in only when the MVG is secure.
MVG and fixed ship dates
When a ship date is fixed (publisher contract, platform certification window, retail slot), the MVG is the tool that makes the date achievable. The logic:
- Define the MVG — the non-negotiable core
- Estimate the MVG in story points; compare to team velocity
- If the MVG cannot fit in the available time, it needs to be reduced — not the date
- Everything beyond the MVG is explicitly optional and subject to cut
This makes scope cuts a planned part of delivery rather than a crisis response. The publisher or stakeholder can see exactly what is being traded and why.
MVG and risk management
The Product Backlog should order features by risk as well as by value — the riskiest, most uncertain features should be tackled early, not deferred. This is because:
- Risk discovered late is expensive to resolve
- A feature that turns out to be impossible at beta (when all the other features are integrated) has consumed backlog space that could have gone to lower-risk features
- Early risk reduction also produces early learning about what is fun — which directly informs the MVG definition
Keith’s example from the Darkwatch project: animation technology was developed according to a plan that called for many unique features to be completed before any were proven. Limb-severing was being built while basic transitions were still broken — a classic case of complexity-prioritised rather than value-prioritised development.
MVG for indie and student projects
The MVG concept is especially important for small teams with limited time. Keith notes that Agile practices benefit indie developers directly by:
- Keeping focus on completing the core loop before adding scope
- Providing a framework for deciding what to cut when time runs short
- Enabling early playtesting (the Sprint Review) that reveals whether the core is fun before too much is built on top of it
For a student project with a 12-week deadline: the MVG might be one level, one mechanic, and a win/lose state. Everything else — additional levels, UI polish, audio — is explicitly optional and prioritised in the backlog.
In practice
Defining the MVG in a Unity project:
- Write user stories for every feature you want the game to have
- Sort them into three buckets: Must Have (MVG), Should Have, Nice to Have
- Estimate the Must Haves in story points
- Compare to available sprint capacity (velocity × remaining sprints)
- If Must Haves exceed capacity, move some to Should Have and revisit
The Must Have bucket defines your MVG. Protect it. Build everything else on top.
Evidence
“[The MVG concept] protects the ship date by making scope cuts explicit rather than allowing invisible debt to accumulate.” (Keith, Ch. 10, paraphrased)
“The purpose of [risk-first ordering in the product backlog] is to address the most uncertain, riskiest parts of the game first so that stakeholders and the team can make informed decisions about the game’s future before too much time and cost is invested.” (Keith, Ch. 10, paraphrased)
Implications
- A project without a defined MVG has no principled way to make cuts under pressure — it will cut whatever is least finished, not whatever is least valuable
- The MVG evolves as the team learns — it should be revisited every few sprints, not locked at the start of pre-production
- Publisher milestone payments are most safely structured around MVG milestones, not arbitrary feature lists
Open questions
- How do you define an MVG for a game with strong narrative elements, where the “core” includes story beats?
- At what point does the MVG become too small to be a viable commercial product, even if it is technically complete?
- How does the MVG concept interact with early access and games-as-a-service models, where the first release is explicitly not the finished product?
Related
overview-full-game-development-pipeline | scrum-in-game-development | product-backlog | sprints | prototyping | agile-design | build-and-release-management | game-marketing-fundamentals | overview-agile-game-development | source-agile-game-development