Blog

Game Project Management: A Copyable Setup for Tiny Crews

By Lauren "Celeste" Rousell · October 18, 2026 · 10 min read

Game project management for a 2-8 person crew works best as three layers: milestones (vertical slice, alpha, ship), sprints of one to two weeks inside each milestone, and a kanban board with an asset-review pipeline attached. Below is the exact board structure, card fields, and workflow to copy today.

How Is Game Project Management Different From Generic Software Project Management?

Game production breaks generic boards because three things behave differently here.

Milestones drive scope, not dates

A vertical slice or milestone defines what ships, and scope flexes to hit it. Generic PM assumes the backlog is fixed and the calendar moves; game production does the opposite.

Assets have dependencies code does not

A character model blocks rigging, which blocks animation, which blocks the build. A kanban card that says "done" when the art is approved still leaves code waiting. Dependency chains run through the pipeline, not just the sprint.

Disciplines work on different cadences

Code lands daily, art iterates over weeks, audio arrives late. One board with one workflow forces all four disciplines into the same rhythm.

That's why studios adopt game-specific tools: Codecks users report that keeping design docs next to task management creates real efficiencies. The same logic drove us to build Inferno for game crews rather than around generic columns.

What Should a Tiny Crew's Board Structure Look Like?

A 2-8 person crew needs one shared board with six columns, not a maze of swimlanes. Generic kanban stops at "To Do / Doing / Done"; game production needs columns that reflect how work actually moves through a pipeline: designed, built, reviewed, integrated into the build.

Recommended columns for a 2-8 person team

The Review and In Build columns are the ones generic boards skip, and they're where tiny crews lose track of what's actually shippable.

When to split boards per discipline

Split only when a discipline's review flow differs structurally, usually Art. A separate art board with its own Review column keeps asset feedback from clogging the main board. Code and Audio usually stay on the main board.

One board vs many: the tiny-crew rule

Under eight people, one board wins. If you can't see the whole milestone in a single screen, you'll stop trusting the board and drift back to Discord threads. Inferno is free for indie crews today, and the pricing page has the details.

Which Card Fields Actually Matter for Game Dev Project Management?

Fields worth tracking (and fields to skip)

Six fields cover a tiny crew's needs: discipline tag, asset type, build status, review status, milestone, and estimate. Skip priority levels, sub-assignees, and time-tracking minutiae. With 2-8 people, anyone can reorder a board in thirty seconds, so a priority field just adds upkeep. If a field never changes how a card gets sorted or filtered, delete it.

Discipline tags: Design, Art, Code, Audio

One tag per discipline, single-select, so you can filter "all Art cards blocking the vertical slice" instantly. The tag doubles as a capacity check: when your artist's column holds twenty cards and your audio column holds two, the pipeline bottleneck is visible without a meeting.

Linking cards to builds and commits

Build status should be a short enum: not started, in build, in the current build, shipped. That last state is what kills the "fixed stuff" commit problem, where Monday becomes archaeology through history and chat threads. Review status stays binary: needs review or approved.

We hold Inferno to the same standard. Its task cards cover discipline, estimate, and sprint, but not dedicated asset-type, build-status, or review-status fields, and Code Forge links GitHub repositories only, with no Perforce support. We compare this openly in Inferno vs Codecks.

How Do You Map Milestones to Sprints Without Corporate Overhead?

Prototype, vertical slice, ship: the three-milestone spine

Skip the twelve-milestone production bible. Three milestones carry a tiny crew: prototype (is the core loop fun?), vertical slice (does one slice of the finished game look and play right?), and ship. Everything on your board belongs to one of these or gets cut. Sprints then become short, fixed checkpoints between milestones rather than ceremonies, and each sprint's only job is to move the current milestone forward. If you are new to the middle one, what a vertical slice is covers how to scope it.

Sizing sprints for a 2-8 person team

Run one- to two-week sprints, no longer. With under eight people, a two-week sprint is the longest stretch you can plan without the plan rotting, and a one-week sprint is often better during crunch periods before a milestone. Cap the sprint backlog at what your slowest discipline can finish: if your lone Audio person can ship three assets in a week, a sprint with eight audio cards is fiction. Review on Friday, plan Monday, fifteen minutes each.

Handling scope creep at milestone boundaries

Scope creep doesn't enter mid-sprint; it enters at milestone boundaries, disguised as "one more feature before the slice." The fix is a hard rule: nothing new joins the current milestone unless something of equal size leaves it. When the vertical slice slips, cut content, not the milestone date. If your current tool makes that trade invisible (Trello's freeform boards make it easy to keep piling cards on, which is why some crews move to game-specific boards; see Inferno vs Trello), the discipline has to live in your planning ritual instead: write the cut list down before you write the add list. For more on telling the two kinds of drift apart, read scope creep vs feature creep.

What Does an Asset-Review Workflow Look Like on a Board?

The five asset statuses

Give every art and audio card five columns: Draft, Internal Review, Revision, Final, Integrated. A sprite moves Draft → Internal Review only when the artist considers it shippable, not when they start. This keeps your review column a short queue of finished work rather than a graveyard of half-started concepts. Anything sitting in Revision carries a comment on the card explaining exactly what changed, so nobody re-reviews from memory.

Who signs off: the one-reviewer rule

Name one approver per asset on the card itself, decided by discipline: art lead approves art, audio lead approves audio. Two reviewers means neither reviews. If your tiny crew has no dedicated lead, the person who wrote the original request approves, and the terms you agree on should say so in writing. The requester signs off on Integrated, confirming the asset actually landed in the build.

Blocking dependencies: art waits on design, code waits on art

An asset cannot enter Draft until its design card is Final, and the code card consuming it cannot start until the asset is Integrated. Link the cards so the block is visible without opening Discord. This is the same discipline milestone planning imposes at project scale, where a vertical slice gates further production (see Game Developer on vertical slices).

How Do You Replace the Trello + Discord + Google Docs Stack?

What Trello does well and where it falls short for games

Trello is fine for a flat backlog and simple kanban flow. It falls short once you need milestone rollups, discipline-based filtering across Art and Code, or asset reviews attached to the cards they ship with. Generic boards treat every card the same; game production does not.

What stays in Discord (and what shouldn't)

Keep Discord for voice, hangouts, and build announcements. Move decisions that affect scope or milestones out of chat and onto cards, where they survive longer than a scroll. If a conversation changes the backlog, its outcome belongs in the workspace, not pinned in a channel.

Consolidating design docs with tasks

Google Docs fragments your game design documentation from the work itself. Attach design notes directly to the cards they describe so context travels with the task. That is the core promise of purpose-built tools like Codecks and HacknPlan, and it is what Inferno builds its workspace around. Our game design document example shows how to size the doc itself.

How Do Purpose-Built Game Tools Compare for a Tiny Crew?

Criteria from this setup, applied to all five

Judge each tool on what this article built: milestone-first boards, card fields tied to discipline and build status, an asset-review loop, and one workspace replacing the Trello + Discord + Docs stack. HacknPlan and Codecks both score well here because they were designed for game production, not adapted to it. Projects.ink is the lightweight option in that same category. Trello can mimic the board structure, but generic cards mean you bolt on the milestone and asset-review pieces yourself. Codecks users report that keeping design docs next to tasks creates real efficiencies.

Where Inferno falls short

Inferno is honest about the same gap: it has no built-in asset markup or per-frame review, so art approval still routes through screenshots and comments. If your pipeline is asset-heavy, HacknPlan's review tooling runs deeper.

Choosing by team shape, not feature lists

A 2-8 person crew across Design, Art, Code, and Audio should pick the tool whose defaults match how you already talk. If chat-like flow matters most, Codecks wins. If milestone discipline matters most, HacknPlan. If you want one workspace and can live without deep asset review, Inferno.

What Does This Setup Look Like for a 48-72 Hour Game Jam?

Jam scope is a vertical slice compressed into a weekend, so strip the system to one board, three columns, and no estimates.

The three-column jam board

Columns: Doing, Done, Broken. Every card is one shippable unit: "player can dash," "one room with art," "loop audio." If a card can't be demoed when it's Done, it isn't Done, it's Broken. No discipline labels, no milestones, no asset-review column; review happens by pointing at the screen.

Post-jam: turning the jam board into a backlog

When the jam ends, move surviving cards into a fourth column called Backlog and you have the seed of the full system from earlier sections. Anything in Broken gets a one-line note on what failed. That note is the difference between "fixed stuff" and knowing what the code was supposed to do when you pick it up three months later.

FAQ

What is the best project management software for game development?

There is no single best tool; it depends on your team shape. Purpose-built options like Codecks, HacknPlan, and Inferno handle milestones, discipline tags, and asset review out of the box. Generic boards like Trello require you to build those pieces yourself. Pick the one whose defaults match how your crew already communicates.

Is Trello good for game development?

Trello works for a flat backlog and simple kanban flow. It falls short once you need milestone rollups, filtering across Art and Code, or asset reviews attached to the cards they ship with. Generic cards treat every task the same, so tiny crews usually outgrow it and move to game-specific boards.

How do indie game teams manage projects?

Small teams typically run three layers: milestones like prototype, vertical slice, and ship, plus one- to two-week sprints inside each milestone, and a single shared kanban board with review and build columns. Decisions affecting scope live on cards rather than in chat, and each sprint moves the current milestone forward.

What is game design project management?

It is the practice of planning game production around milestones and asset pipelines rather than fixed dates and backlogs. Scope flexes to hit a vertical slice, art assets carry dependency chains through rigging and animation, and each discipline works on a different cadence, so the board must track review and build status, not just completion.

Do I need project management for a solo game dev project?

A full system is overkill, but some structure still helps. Track your milestones and keep a simple board so scope creep stays visible, even with one column for doing and one for done. The discipline of writing down what gets cut matters more than the tool you use to track it.