A game jam plan your whole team can see and edit

What this board can't do for a game jam

• No reminders and no timer. Nothing tells you it is hour 24. The checkpoint cards are words on the board that your team agrees to look at.
• No timeline axis. The hours in the example (H0, H6, H24, H36, H44) are text on cards, not positions on a time line. The board's Calendar view places cards on days, not hours.
• No version control and no file store. A free board holds 3 images and 1 file of up to 10 MB per board. Keep art, audio and code in your repo or a shared folder and write where to find each asset on its card.
• An arrow is only a line. You choose its caption and colour. It doesn't know a feature is blocked when its asset is late; you read the arrows yourself.
• Check an arrow after you move its card. Arrows between cards in different lists stay attached when cards are reordered inside a list and when a whole list moves. We haven't tested what an arrow does when its card is dragged into another list, so look at it after you move one.
• 150 items on the free plan, across your account. Each card and each list is 1 of the 150. The example is 53. Any other board on your account counts too. Pro is $5 a month billed yearly ($59.99 a year) and removes the item limit.
• 5 boards and 3 images per board on the free plan. A teammate who opens your link uses 1 of their own 5 boards, and cards they add count toward their own 150.

How to plan a game jam on one board

This is how the example board is used. The hours are the example's own, for a 48-hour jam with four people; they are not a rule.

1. 1Write the one-page design first (see below). In the example one person writes it in the first hour, after a brainstorm.
2. 2Sort every feature into one of three lists. Must is what makes the game playable. Should is what you add if Must is done. Cut is what you already know you won't finish. Put the Cut list on the board on purpose; an item that is written down is easier to drop.
3. 3Give each person a list. The example has Ines (design), Theo (code), Mara (art) and Jun (audio), each with a few cards that say what and by when.
4. 4Put every asset on the Assets list and point an arrow at the feature that needs it. The cave tileset points at "Three cave rooms", the pickup chime at "Oil pickups". When an asset is late, you see which feature waits for it.
5. 5Write the checkpoints. The example has H0 theme drops, H6 scope agreed, H24 playable, H36 stop adding and H44 build and upload. The H24 card points at the Cut list: if the Must list isn't playable at that hour, cut from the Cut list there.
6. 6Move cards between lists as the jam goes. A Should card that is done goes out of the way; a Must card that slips is a signal to cut.

A written account of one jam team's process, Game Developer's "Game Jams: an agil-ish approach" (July 23, 2020), describes similar steps for a 72-hour jam: break the project into a features list, prioritize it as a team (it names the MoSCoW method of Must, Should, Could and Won't have, and suggests Iteration 1, 2, 3 instead), work in sprints of four to six hours, and once the jam is six or fewer hours from the end, stop adding and polish. Its author tracked sprint work in Trello or Excel and kept the team's written agreements in a Google document. That is one team's method, not a rule.

A one-page game design document on the board

A full game design document is long, and a jam is short. Indie Game Academy's guide (April 29, 2025) says a design document helps keep a project realistic and stop scope creep, and that this is especially useful for a game jam. The example board's "One-page design" list is the small version: five cards for name and theme, aim and main mechanic, core loop, win and lose, and open questions.

The fields come from a one-page template that u/gossiossioss posted in r/gamedesign (May 30, 2023) for smaller projects and jam games: game name, theme, genre, audience, story, visual and audio style, a main aim, a main mechanic, enablers and blockers, the core loop, win and lose conditions and any additional features. In the replies, u/PhilippTheProgrammer suggested calling "Story" "Narrative", merging visual and sound style into "Aesthetics" and adding a "Controls" section. That is one designer's template and one commenter's edits, not a standard. On a board you can add or drop a card for any of them.

A board card holds a short answer, not a document. If your team wants a long written design, write it in a document and keep the one-page version here.

What one big jam team learned

These are single accounts, not a measured pattern. In r/gamedev (August 31, 2025), u/Klightgrove described leading a 50-person team in a jam, with 48 credited developers at the end. They promoted a lead for Art, Audio, Design and Programming, and said the flip side of people joining over time was a lot of administrative work, including constantly updating spreadsheets of people's skills. Their takeaways included "Plan your stretch priorities wisely" and building the team "on a small rock first", meaning securing the essential roles before adding depth in one area, and they reported merge conflicts from several people working in the same scenes.

A four-person team is not a 50-person team. But the same idea holds at any size: say who owns what and what is a stretch goal before the work starts. On the board, owners are the lists and the Should and Cut lists are the stretch goals.

Set up the board with your team

1. 1In the share menu, set "Anyone with the link can edit". New boards start view-only.
2. 2Send the link, or the 4-digit join code. The code expires after 2 hours of inactivity, so send the link to anyone you'll need later.
3. 3Each person signs in free (Google, Apple or email) to write. Someone who isn't signed in can open the link and read everything, but can't change anything. Once they're signed in, what they move or add shows up on your board within a few seconds, and you see theirs the same way.
4. 4If they're already at 5 boards, they can still open the link and write; the board just isn't added to their boards.
5. 5Give each person their own list. If two people type in the same card at once, the two edits merge letter by letter with no lock, so keep cards single-owner.

Free calls on the board run up to 60 minutes per call, with a warning 10 minutes before the end; everyone signs in free, calls aren't recorded, and Pro has no limit. If your jam game is a puzzle adventure, the puzzle dependency chart board is built for that part, and for a branching story there is the visual novel planning board.

Jam planning tools, side by side

Each row is from the tool's own page, read on November 11, 2026. Features and prices change, so check the page before you choose.

When another tool is the better choice

• Your tasks live next to your code. GitHub Projects syncs with issues and pull requests, so a programmer-only team may prefer it. A board shows the plan, not the commits.
• You want a task tracker that tells people what is theirs. Trello's free plan lists assignee and due dates and iOS and Android apps. On a board you can assign a person by typing @ on a card, but nothing notifies them.
• You need a timeline. Trello's Timeline and Calendar views are on its Premium plan. This board has no timeline; its Calendar view places cards on days.
• You want long written text in one place. The article above kept its team's written agreements in a Google document. A card holds a short answer, not a long document.
• You want to see what changed in the code. A board can't show that; your repo can.

Questions