Project management in game development: from pre-production to launch

Project management in game development coordinates scope, schedules, dependencies, and release decisions from pre-production through launch. It helps a team decide what to build next, who is responsible, and what must be verified before work moves to the next stage.

Imagine a team preparing its vertical slice. The enemy model is approved, the combat code is merged, and the level is ready for review. But the attack animation still needs work. Audio is waiting on its timing, and QA has yet to test the encounter with everything in place.

Several tasks are finished. The team still cannot assess the complete encounter.

A producer needs to see which unfinished work prevents the encounter from reaching the build, who can resolve it, and whether the delay affects the milestone.

What game project management covers at each development stage

The next decision depends on the stage. Studios may combine stages or define them differently, so agree on what each milestone means for your project.

Define game development milestones by the build or decision each one must deliver, and record its exit criteria. At each review, compare the result against those criteria and identify any work still required before proceeding.

Pre-production: connect game design to a testable plan

Game design defines the experience you want players to have: the choices they make, the rules they learn, and the feedback they receive. In pre-production, turn the uncertain parts of that design into questions the team can investigate. For the arena encounter, one question might be whether players can recognize an incoming attack in time to respond.

Give each prototype a question, an owner, and a review date. Record what the test changed in the plan before committing to the next experiment.

Keep the current design in a game design document, with links to the tasks that implement it. Macro design covers player abilities, progression, and scope; micro design develops the detailed encounters during production. For the arena, link the attack specification to the animation, sound, and code tasks that implement it.

If your team calls this a game development document, define its scope and link to the current design, technical specifications, and milestone plan.

When an attack changes, the people building and testing it should be able to find the current decision from their tasks.

Define exit criteria for the vertical slice

A vertical slice milestone needs a playable target and evidence that the team can deliver more work at the same quality. For the arena example, the target could be:

A player can enter one arena, fight two enemy types, receive a reward, and restart after defeat. The encounter is playable from beginning to end on the target hardware.

For this illustrative project, agree on exit criteria before the review:

• QA can complete the full arena sequence in an identified build without developer intervention.
• Named reviewers approve the encounter's visuals, animation, audio, and interface against the intended release quality. A playtest checks whether players can recognize and respond to the enemy attacks.
• Performance measurements on the agreed target hardware meet the project's recorded limits; the review includes the build identifier and test results.
• Another team member can follow the documented asset and integration steps. The team records effort, rework, and waiting time, then uses them to estimate the next encounter and identify tooling work still needed.
• Each unresolved issue has an owner and an explicit decision: fix before approval, investigate further, or accept a documented limitation.

Keep additional arenas outside this milestone's scope. If the encounter works but creating the next one still depends on unplanned manual work, record that production risk before approving the next batch of content.

Production: follow each feature across disciplines

A game development team brings together people whose contributions to a feature often overlap. Agree on an owner for each contribution, and make the handoffs explicit.

Use the handoffs tested in the vertical slice to define your game production pipeline. For each new encounter, a small planning table could look like this:

This is an illustrative sequence; your team may work in parallel with temporary assets. Record those arrangements so everyone knows which work can proceed and which checks must wait.

Keep discipline tasks connected to the feature and milestone they support. An artist needs to see the next review. A producer needs to see whether that review affects integration or the build date. Both should be looking at current information about the same work.

Agile game development with Scrum

Scrum organizes work into sprints lasting a month or less. The Product Owner is accountable for ordering the Product Backlog; the people doing the work select and plan what they can complete toward a shared Sprint Goal. The Scrum Master helps the team use Scrum effectively. These accountabilities are defined in the Scrum Guide.

For a game development team using Scrum, a useful sprint goal might be to make the arena encounter playable with readable enemy attacks. Select a small enough piece of gameplay that the required design, implementation, and testing can happen within the sprint. During prototyping, an iteration could use one enemy and a temporary environment, if that supports the goal and meets the team's quality standards. A vertical slice milestone may span several sprints.

Agree on a Definition of Done that covers integration and verification. For this project, it might require that completed gameplay changes run in the shared build, pass the agreed checks, and have updated design notes. This lets animation, engineering, and QA plan toward the same usable result.

Use the Daily Scrum to adjust the work toward the goal, the Sprint Review to inspect the outcome with stakeholders, and the Retrospective to improve how the team works. As the team learns, scope can be renegotiated with the Product Owner while protecting the sprint goal.

For help defining task stages, ownership, and handoffs within a sprint, see our guide to agile workflows.

Turn playtest findings into assigned changes

Playtests should lead to explicit decisions about the next build. Adding every observation to the current milestone can leave the team with more work than it has time to finish.

Suppose testers struggle to read an enemy attack. Record the observation and build version, then investigate the cause. The problem could be animation timing, the camera angle, or a sound cue. “Improve combat” is too broad for someone to act on.

Once the team chooses a change, assign it and define how it will be checked. For example: adjust the attack wind-up, integrate it, and run another test focused on whether players recognize the warning.

Keep the outcome beside the work. If the change fails to solve the problem, the next discussion can start with what was tried and observed.

Make scope changes visible in the schedule

Scope creep in game development occurs when features or content are added without reviewing their effect on the agreed plan. Check every affected contribution before accepting a change.

For the arena vertical slice, adding a third enemy type might require design work, a model, animation, audio, balancing, and another QA pass. Even if one person has spare capacity, the people needed later in the sequence may already be committed.

Check the impact with those owners. Then decide whether to replace other work, reduce the proposed addition, move it to a later build, or revise the milestone date.

A short decision record is enough:

Third enemy deferred until after the vertical slice review. The slice keeps two enemies so animation and QA can finish the agreed encounter. Revisit when planning the next production milestone.

Update the affected tasks and design notes when the decision is made. Otherwise, an old request can remain active after the team has agreed to defer it.

From alpha to release candidate: review remaining work

At the alpha review, compare the agreed feature scope with the integrated build. For the arena game, that includes the path from entering a fight to receiving a reward and saving progress. If a planned system is missing, record the work required or approve a scope change before accepting the milestone. Give each remaining item an owner and an estimate.

During beta, review unresolved defects alongside requests to change completed content. If a designer proposes changing attack timing, identify which animations, sound events, encounters, and tests must be revisited. Decide whether the change is needed for launch and schedule the resulting rework. Record which build QA should verify after the fix.

For each release candidate, track the exact build under review and the checks still open. Keep final regression results, platform approvals where required, and launch blockers attached to that candidate. If a blocker requires another build, record which checks need to run again. Assign someone to make the release decision against the agreed criteria.

Schedule the remaining fixes and verification against actual availability, including support and review commitments. If the work no longer fits, make the scope or date decision before committing to the release.

Plan ownership for launch and live updates

Agree on launch coverage before the build goes live. When an issue arrives, the team should know where to record it, who will investigate, and who can decide whether it requires a hotfix.

For example, if a player reports that an encounter cannot be completed, capture the affected build, platform, and reproduction steps in the task. Connect the fix and its verification to the update intended to deliver it. This keeps the support report traceable through to the change players receive.

Track milestones and dependencies in Vaiz

Vaiz keeps tasks and project documents in one workspace. To organize the arena vertical slice, create a brief with the playable target, exit criteria, and the person responsible for accepting the milestone.

Add the animation, audio, integration, and QA tasks, each with an owner. Link the dependencies that determine when the next task can start. Team members can use board or list views for their daily work, while the producer uses Gantt to review the tasks, dependencies, and milestone together. See Vaiz for game studios.

If the attack animation is delayed, check which audio and integration tasks depend on it and whether the QA window still fits. Record the resulting decision in the affected tasks and milestone brief so the next review starts with the updated plan.

If you're choosing software to support this process, our comparison of project management tools for game developers covers Vaiz, Codecks, and HacknPlan.

FAQ

Who should own the project plan in a small game team?

Assign one person to maintain the plan and surface decisions, even if they also do design or development work. Task owners should update progress and blockers. The team should also agree who can approve changes to scope or dates.

What should a game development project plan include?

Include the current development stage, the next milestone and its exit criteria, committed scope, task owners, dependencies, and expected dates. Make unresolved decisions and assumptions visible, and allocate time for integration and testing.

When should the team update the plan?

Update it when a decision, estimate, or blocker changes the expected work or delivery date. Use the production review to check the whole plan together. Urgent blockers need attention when they appear.