Stephen Brenish
Your team just wrapped a killer prototype. The creative director is buzzing, stakeholders are nodding, and someone tapes a sprint board to the wall. Two weeks later, half the tickets are stuck in “In Progress,” nobody can agree on what “done” means for a concept exploration task, and the lead designer hasn’t touched the board in a week because she’s busy writing a 30-page GDD that will probably change three more times before alpha. Sound familiar? That’s not a discipline problem. That’s Scrum colliding with a phase it was never built for.
What Pre-Production Actually Is (and Why It’s Different)
Pre-production is a discovery process. You’re trying to answer questions you don’t fully know how to ask yet. What’s the core loop? Does it feel fun? What’s the production risk? Can we actually build this with the team and budget we have? The deliverables are fuzzy by design, because the whole point is to reduce uncertainty, not ship increments of a known product.
Scrum was designed for something else entirely. It assumes a stable product backlog, a clear definition of “done,” and incremental delivery of working software. It works beautifully when a feature team is implementing a login system, adding weapon skins, or fixing a regression in a lighting system. The work has shape. The output is verifiable.
Pre-production breaks those assumptions completely. You might spend three days building a prototype that gets thrown away on purpose. A designer might need two weeks of open-ended play research before she can write a single user story. A technical director might need to spike on three different engine approaches before the team can scope anything at all. None of that maps cleanly to a two-week sprint with defined acceptance criteria.
The Specific Ways Scrum Fails the Phase
Let me be specific about the failure modes, because “Scrum doesn’t fit” is easy to say and hard to act on.
Sprint velocity becomes meaningless. In production, velocity is a useful forecasting tool. You track story points over time, smooth out the curve, and get a reasonable estimate of throughput. In pre-production, the work is so heterogeneous that point estimates are almost pure fiction. How many story points is “figure out whether we want a stamina bar”? You could assign three points and close the ticket in a day, or you could assign three points and still be debating it six weeks later. The metric teaches the team nothing.
Definition of Done creates false confidence. When you force a DoD onto exploratory work, one of two things happens. Either you write acceptance criteria so vague they’re useless (“prototype feels fun”), or you write criteria that are technically completable but don’t actually answer the creative question. I’ve watched teams ship “functional” prototypes that cleared every sprint criterion and still couldn’t tell leadership whether the concept was worth pursuing. The checklist got checked. The real question stayed unanswered.
Two-week cadence fights against creative iteration. Some pre-production work runs on a shorter feedback loop. A game feel prototype might need daily or even hourly feedback from the creative director. Some work runs much longer. Writing a tech design document for a procedural generation system might take four weeks of research plus writing. Forcing both into the same two-week box either rushes the slow work or bores people waiting to review the fast work.
The backlog becomes a graveyard. Pre-production backlogs have a specific disease: they fill up with tickets that represent open questions rather than tasks, and open questions don’t get “done,” they get answered or abandoned. When the product owner dutifully grooms that backlog, they’re often just reshuffling uncertainty. Teams start to feel like the process is busywork, which is death to morale during a phase where you absolutely need creative energy.
A Better Mental Model: Pre-Production as Structured Inquiry
What I *actually* do as a Product Manager (in 2023) · Chloe Shih on YouTube
Think of pre-production not as a mini-production sprint sequence, but as a series of time-boxed experiments with explicit exit criteria. The question you’re answering isn’t “did we complete this sprint?” It’s “did we reduce uncertainty enough to make the next decision?”
This reframe changes everything about how you structure the work. Instead of a backlog of tasks, you maintain a list of open questions ranked by risk and dependency. Instead of sprint goals, you set experiment goals: “By the end of week two, we will know whether physics-based traversal is technically feasible on our target platform.” That’s a pass/fail question. The team knows what they’re running at.
This is closer to how the best pre-production teams I’ve seen actually operate, even when they’re officially “doing Scrum.” They’re running Scrum on the outside and something closer to hypothesis-driven development on the inside. It’s worth formalizing that instead of pretending the sprint board captures the real work.
What to Use Instead (or Alongside)
You don’t have to throw out every Agile tool. You just have to be selective.
| Scrum Element | Pre-Production Alternative |
|---|---|
| Sprint backlog of tasks | Risk register of open questions, ranked by impact |
| Two-week sprints | Variable-length exploration cycles (1, 2, or 4 weeks) tied to specific decisions |
| Velocity tracking | Decision throughput: how many key questions answered per month |
| Sprint review demo | Playable prototype review with explicit “what did we learn” debrief |
| Definition of Done | Explicit “question answered” criteria written before the experiment starts |
| Daily standup | Shorter, question-focused check-ins: what’s blocking a decision? |
Kanban is often a better fit than Scrum for at least part of pre-production. It handles variable cycle times naturally and doesn’t punish you for work that spills past a two-week boundary. Tools like Jira, HacknPlan, or even a physical board with swimlanes organized by risk category can work here. HacknPlan in particular was built for game development workflows and handles milestone-based planning better than a pure ticket queue.
Weekly milestones work better than sprints during this phase. Define what question you’ll answer or what prototype you’ll have by end of week, keep the team pointed at that, and run a lightweight retrospective focused on “did we answer the question and what did we learn?” not “did we hit our velocity target?”
For producers who want to go deeper, The Art of Game Design by Jesse Schell has a solid lens on iterative design thinking that maps well onto pre-production planning, even though it’s not explicitly a production methodology book. Blood, Sweat, and Pixels by Jason Schreier is great for understanding how real pre-production actually went on shipped games, warts and all. For timing your phases, the game development schedule planner lays out pre-production, the vertical slice and later gates from a target date.
How to Transition Your Team Without Blowing Up Trust
If you’re a producer trying to change the process mid-pre-production, be careful. Teams that have been told “we do Scrum” and then suddenly get told “never mind, we’re doing something else” will often hear “our process is a mess and leadership doesn’t know what they’re doing.” You need to frame the change accurately.
Here’s a step-by-step approach that works:
Name the problem in a retrospective. Don’t show up with a new framework already decided. Ask the team: “What’s not working about our current process?” Let them say the things they’ve been noticing. Usually they’ve noticed everything.
Introduce the experiment framing. Explain that pre-production is fundamentally about answering questions, not shipping increments. Write out your top ten open questions as a team. Rank them by risk and dependency. This exercise alone often clarifies the real work more than a full sprint backlog.
Keep the cadence but change the goal. Don’t change your meeting rhythm yet. Keep standups, keep a weekly sync. But replace sprint goals with question goals. “This week we answer: can our AI systems support 40 NPCs at target framerate?” That’s it. Keep everything else familiar.
Introduce variable cycle lengths slowly. After a few weeks, if the team agrees, try a four-week deep-dive on the biggest technical risk. Compare how that felt versus cramming it into two-week chunks. Let the team’s experience drive the decision.
Use a productivity tool to track decisions, not tasks. Notion, Confluence, or even a well-structured Google Doc works for a decision log. Every answered question goes in: what was the question, what did we find, what do we do next. This becomes your pre-production artifact and your institutional memory.
Define your pre-production exit criteria before you start. This is the hardest part and the most important. What questions must be answered before production can start? Lock that list before the phase begins. That list is your actual milestone, not a sprint count.
Signs Your Pre-Production Scrum Is Actively Hurting You
| Scrum Element | Pre-Production Alternative |
|---|---|
| Sprint backlog of tasks | Risk register of open questions, ranked by impact |
| Two-week sprints | Variable-length exploration cycles (1, 2, or 4 weeks) tied to specific decisions |
| Velocity tracking | Decision throughput: how many key questions answered per month |
| Sprint review demo | Playable prototype review with explicit “what did we learn” debrief |
| Definition of Done | Explicit “question answered” criteria written before the experiment starts |
| Daily standup | Shorter, question-focused check-ins: what’s blocking a decision? |
Sources
- did we reduce uncertainty enough to make the next decision? This
- did we hit our velocity target? For
- before she can write a single user story
- plus writing
If you’re unsure whether this applies to your current project, look for these signals:
Your sprint board has more than 20% of tickets in “In Progress” at any given time, and they’ve been there for more than five days. Your team is spending significant time in backlog grooming sessions but nobody’s confidence in the schedule has improved. The same creative questions keep coming up in retrospectives without resolution. Your velocity graph is erratic enough that it provides no forecasting value. And the tell that I’ve seen more than any other: your creative director or lead designer has quietly stopped engaging with the process because they feel like the board doesn’t reflect what they’re actually doing.
That last one is the most dangerous. When your most creative people decouple from the process, you don’t lose their productivity immediately. You lose it gradually, and you lose the process’s ability to surface creative risk, which is exactly what you need pre-production to do.
Pre-production is where games live or die. Get it wrong and you spend production fixing design problems that should have been caught earlier. That’s the most expensive possible time to catch them. The framework you use during this phase should be designed to maximize learning speed and creative clarity, not task completion rate. Scrum is a great tool. It’s just not always the right tool for this job, and knowing the difference is one of the things that separates a good producer from a great one.
Photo: cottonbro studio via Pexels
