Blog

Game Jams: A Task Board Playbook for Tiny Indie Teams

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

Run game jams on a task board with columns mapped to each phase: pre-jam setup, the jam itself, and post-jam triage. This guide gives you the exact column layouts and card hygiene rules for 48-hour and week-long formats, so your tiny crew spends the clock building instead of deciding what to build next.

What is a game jam and how does one work?

A game jam is a timed event where a team builds a playable game from scratch around a theme announced at the start. You get the theme, you scope something shippable within the timebox, and you submit a build before the deadline. No extensions, no scope creep you can afford.

Common jam formats and timeboxes

The most familiar formats are 48 hours (Ludum Dare's compo), 72 hours (its jam tier), and week-long community jams on itch.io. Ludum Dare's rules require the compo's theme to be revealed at kickoff and work to be made from scratch during the event.

What the theme reveal actually constrains

The theme forces a fresh concept, so your pre-jam prep covers pipeline and tooling, not the game itself. For a tiny crew, that means your task board should be ready before the theme drops, so hour one goes to brainstorming instead of setup. Tools like Inferno are built for exactly that kind of tight, shared planning.

How should a team set up tasks before a game jam starts?

The 10-card prep backlog

Write ten cards before the jam: pick the jam, confirm the date, agree the engine, list each discipline's role, define "shippable," set a build checklist, choose the board tool, draft column names, agree a daily check-in time, and name one person who can cut scope. That is the whole prep backlog. Anything else is scope creep before the theme even drops.

Locking roles and the tool stack before the theme drops

The single highest-leverage decision a tiny crew makes before a game jam is agreeing, in writing, what "shippable" means and who owns which discipline. Write it as one card: shippable means a build that runs on the target platform, one core loop, and a title screen. Assign Design, Art, Code, and Audio owners, with a named backup per discipline, because someone will get sick at hour 30. Then pick one tool and stop debating.

A shared board on Inferno keeps the backlog, roles, and build checklist in one place, so nobody is reconstructing decisions from a Discord scroll-back at 2 a.m. Agree that only the scope-cut owner merges scope changes into the board. Post your team's privacy expectations too: link your shared workspace's data policy, for example the Privacy Policy for Inferno, the Game Task Board, so everyone knows where jam material lives.

What task board columns fit a 48-hour or week-long jam?

A 48-hour jam board needs five columns: Idea, Today, Doing, In Build, Done. Week-long jams add a Backlog ahead of Today and a Polish column before Done. The shorter the timebox, the fewer columns you can afford to maintain.

48-hour board: Idea, Today, Doing, In Build, Done

Idea holds every half-formed concept; anything not picked by hour two dies there. Today is your only planning column, re-sorted each morning. Doing is what someone is actively building right now. In Build means the feature is merged and you're waiting on a runnable build to verify it. Done means it's in the playable build.

Week-long board: adding a Backlog and Polish column

With more time, scope creep becomes the real enemy, so a Backlog lets you park "wouldn't it be cool if" ideas without acting on them. Polish holds cards that work but look, sound, or feel rough.

Card hygiene during the crunch

WIP limits matter because a jam team of five can be spread across time zones and disciplines, and most teams mix experience levels, so a shared board replaces verbal coordination. If your board lives alongside your docs and chat, like the setup we compare in Inferno vs Codecks, card updates cost seconds instead of a context switch.

How do you scope a jam project so it actually ships?

Scope is the difference between a shipped build and a folder of broken scenes. Three rules keep a tiny crew honest: one mechanic, one screen, and a cut list written at hour two.

Write the cut list before you write the code

At hour two, list every feature you want, then mark half of them as cut. This is your scope creep firewall. When someone proposes a new system mid-jam, something on the list comes out to make room. Put the cut list on your board as a column of parked cards so the trade is visible to the whole crew. A board built for jams, not generic kanban, makes this painless; we compare our own setup against Trello in Inferno vs Trello, including where a plain Trello board honestly works fine for a weekend jam.

The one-mechanic rule

Pick a single verb: bounce, stack, dodge, slice. Every card on the board must serve that mechanic. The vertical slice comes first: one playable moment with art, sound, and juice, shipped by the halfway mark. If the slice is fun, everything after is expansion. If it is not, you found out with a day left to pivot.

How do you divide roles on a small jam team?

Assign one owner per discipline and let the board show handoffs. A card moves only when its next owner pulls it, so nobody waits on a meeting to know what changed.

Role split for a 4-person crew

One person each for code, art, audio, and design, with design acting as the scope gatekeeper. The designer writes cards as shippable slices: "graybox arena + one weapon" beats "combat system." Code and art pair on anything that touches both pipelines, and audio gets cards early, since sound is what most jam teams bolt on at hour 40 and regret. Post-mortems on Game Developer repeatedly flag late audio and unclear ownership as reasons jam prototypes stall.

Solo and duo variants

Solo devs wear all hats, so label cards by discipline instead of by person and timebox each: two hours of art, then switch. On a duo, swap hats daily rather than splitting code/art permanently; it prevents one person becoming a bottleneck. Either way, keep one backlog column per discipline so the board, not memory, tracks the pipeline. We built Inferno around exactly this crew size.

Which common game jam planning mistakes derail teams?

Scope creep disguised as polish

The jam starts with a vertical slice, then someone "just adds" a particle effect, then a settings menu. Each card looks small; together they eat your build hours. Write a cut list before the jam starts: features ranked by what ships without them. When the clock runs short, cut from the bottom instead of debating mid-sprint.

The board nobody updates after hour 12

By late night, cards stop moving and the board becomes fiction. Someone fixes the audio pipeline but never drags the card, so the crew re-does work or assumes it's broken. Assign one person a 30-minute board sweep at each milestone checkpoint: close dead cards, mark what actually shipped.

The related failure is the "fixed stuff" commit with no card reference, which turns Monday into archaeology through Discord threads. A one-line convention fixes it: every commit message names its card. If your board can't survive a 2 a.m. typo-level update, your discipline will collapse exactly when the build is broken.

What should you do with a jam prototype after the event ends?

Most jam builds die in a downloads folder. Spend one hour turning yours into a decision instead: graduate, archive, or kill.

The post-jam triage board

Clone your jam board and cut it down to three columns: Keep, Backlog, Dead. Move every surviving card into one of them. Anything in Keep gets a one-line note on why it worked, and that note is what makes the prototype reusable six months later. A simple board like Trello handles this fine, but the same three-column sweep works in whatever tool your tiny crew already runs. Cards in Backlog become candidates for your next vertical slice, not obligations. Scope creep after a jam usually comes from treating the prototype as a commitment rather than raw material.

Running a 30-minute post-mortem

Same week, one shared doc, three questions: what shipped, what got cut, what surprised us. Each person writes alone for five minutes first, then you discuss. Assign one owner to move the Keep cards into the studio backlog before the doc goes cold. Otherwise Monday becomes archaeology.

Which task board tools work for game jams?

Criteria: speed of setup, card velocity, game-dev fields

A jam board needs three things. Setup takes minutes, not an afternoon. Moving a card through columns costs one drag, because you will move hundreds. And the tool understands game-dev fields like asset, build, and discipline instead of forcing you to fake them with labels.

How the options compare, honestly

Trello is the fastest to set up and the cheapest to learn, but every game-dev convention lives in hand-built labels and checklists. HacknPlan and Codecks are built for game teams, with discipline-aware fields, though that structure is more than a 48-hour jam needs. Projects.ink targets game docs and planning similarly. t0ggles sits adjacent as a lightweight multi-project board.

Inferno, our own tool, pulls planning, docs, and tasks into one workspace, which shines when a jam prototype becomes a real milestone. Where it falls short: for a pure 48-hour throwaway jam, Trello's blank board is faster to start than Inferno's structured workspace.

FAQ

Can you use a kanban board for a game jam, or is that overkill for 48 hours?

Not overkill, as long as the board stays lean. A 48-hour jam only needs five columns: Idea, Today, Doing, In Build, and Done. The failure mode is a bloated board nobody updates after midnight, not the board itself. Keep work-in-progress limits strict and the drag-to-update cost near zero, and kanban earns its keep even on a weekend sprint.

How many tasks should a team plan for a 48-hour jam?

Plan fewer than you think: roughly 10 to 15 cards total. Commit two cards per person per day in Today, cap Doing at one card per person, and hold In Build to three. Anything beyond that is scope creep wearing a productivity costume. Write the cut list at hour two and park rejected ideas as cards so trades stay visible to the whole crew.

Do solo developers need a task board for game jams?

Yes, but for a different reason: the board replaces your working memory, not your teammates. Label cards by discipline instead of person, and timebox each: two hours of art, then switch. One backlog column per discipline keeps the pipeline visible when you are exhausted at hour 30. A heavy project tool is overkill; a lightweight board with fast card updates is enough.

What do winning jam teams do differently in the first two hours?

They spend the theme reveal brainstorming, not setting up tools, because their board, roles, and definition of shippable were locked before kickoff. They pick one mechanic and one screen, ship a vertical slice with art, sound, and juice by the halfway mark, and write a cut list at hour two. If the slice is not fun, they still have a day to pivot.