Stephen Brenish
Most user stories written for game features are useless. Not because the format is wrong, but because whoever wrote them forgot that games are fundamentally about feeling something, and they wrote requirements instead.
Here’s what I mean. I’ve seen story after story that reads: “As a player, I want a save system so that I can save my game.” Does that tell your engineer anything meaningful? Does it tell your designer what matters? Does it tell QA what to test against? No. It tells everyone exactly what they already knew.
The user story format comes from software development, and it works brilliantly for transactional software, the kind where users have tasks they want to complete. Games aren’t that. Games are experiences with tasks nested inside them. That distinction is everything, and getting it right is what separates a backlog that actually helps your team ship from one that just makes your Jira board look busy.
The Format Is Just the Frame
The classic structure, “As a [type of user], I want [some goal] so that [some reason]”, is fine. Use it. But treat it as a container for meaning, not a checkbox.
The “so that” clause is where most game teams fall apart. On a productivity app, the “so that” is usually self-evident: so that I can track my time, so that I can share the file. On a game, the “so that” is a design argument. It’s you, the producer or designer, making a claim about player psychology. That requires you to actually think.
“As a player, I want a save system so that I can return to my progress without anxiety.” Now we’re somewhere. That word “anxiety” is doing real work. It’s telling your designer that the experience of saving matters, not just the function. It flags that save confirmation UI, the frequency of auto-saves, and the emotional reassurance of the whole system all belong in this story’s scope.
Spend ten extra minutes on every “so that” clause. Seriously. That’s where your team alignment lives.
Writing for the Player Type, Not Just “The Player”
One thing that genuinely changed how I write stories: stop writing “As a player” for everything. Your game has different player types with different motivations, and your stories should reflect that.
A roguelite has the “just one more run” player, the theorycrafter who wants to min-max build paths, and the casual player who’ll bounce if they die three times in the first ten minutes and don’t understand why. Those three players have completely different relationships to the same systems. A story that says “As a player who’s lost a run, I want to see a clear breakdown of what killed me so that I can make a different decision next time” is infinitely more useful than “As a player, I want a death screen.”
This isn’t about writing a separate story for every persona. It’s about being honest about whose experience you’re solving for in any given story. Sometimes one story serves all your players. Sometimes it genuinely doesn’t, and pretending otherwise is how you end up with a death screen that nobody finds satisfying.
Tools like Productboard or even a well-structured Confluence space can help you maintain lightweight player personas that your whole team references. You don’t need a 40-page design doc. You need enough definition that “the progression-focused player” means the same thing to your lead programmer as it does to your narrative designer.
Acceptance Criteria: This Is Where Stories Actually Ship
Codecks -- Game Development Project Management Tool · Gamefromscratch on YouTube
If the user story is the what and why, acceptance criteria is the done and done well. This is the part producers most often skip or delegate entirely to developers, which is a mistake.
Acceptance criteria for game features need to cover three layers you’d rarely think about in enterprise software:
The functional layer: what the system does mechanically. The save writes to disk. The data persists across sessions. Standard stuff.
The experiential layer: what the player perceives. The save animation plays. The confirmation message appears within 500ms. There’s no frame drop during the save. This layer gets skipped constantly, and then QA comes back confused about what “done” actually means.
The edge case layer: what happens when things go wrong. The save fails because the disk is full. The player saves during a cutscene. The autosave triggers mid-combat. Edge cases in games are brutal because players will find every single one of them.
A well-written acceptance criteria block for that save system story might look like this: the player can manually save from the pause menu at any point outside of tutorial-locked sequences; an autosave triggers at every room transition and on every major narrative beat; the save icon appears on screen for 1.5 seconds with an animation; save data persists correctly after a hard close; the game handles a failed save gracefully with a non-blocking notification rather than a crash.
That’s a story you can build, QA, and close. The vague version just generates meetings.
Splitting Stories Without Losing the Plot
Vertical slicing gets preached constantly in agile circles, and it’s correct, but in game development it requires a specific kind of discipline. You want each story to be shippable in isolation, but game systems don’t always cooperate.
The way I handle this: distinguish between a feature story (the full intended experience) and slice stories (the incremental builds toward it). The feature story lives in the backlog as the north star. The slice stories are what actually get pointed and scheduled. Your sprint board should be slice stories. Your product backlog should hold both.
For something like a crafting system, your feature story might be: “As an exploration-focused player, I want to combine found materials into useful items so that I feel like my scavenging has tangible, creative payoff.” Your slice stories might start with basic recipe lookup with hardcoded outputs, then dynamic ingredient substitution, then the discovery mechanic that lets players find new recipes organically. Each slice is testable. None of them are confused for the finished thing.
Linear, Shortcut (formerly Clubhouse, which is what I currently use for most of my work), and Notion all handle this differently. Shortcut’s Epic/Story/Task hierarchy maps onto this approach pretty cleanly if you’re willing to be disciplined about which level each item lives at.
Photo: RDNE Stock project via Pexels
