Vertical Slice: How to Plan, Scope, and Track One
A vertical slice is one fully playable, end-to-end chunk of your game: design, art, code, and audio all working together in a single feature, from input to on-screen result. Build it first, and you prove the core loop is fun before you spend months on breadth. This guide shows how to scope one, slice it into tasks, and track it to done.
What is a vertical slice in software and game development?
A vertical slice is a thin, end-to-end piece of your game that actually works: one feature implemented across design, art, code, and audio, playable from input to feedback on screen. Instead of finishing every system in layers, you build one complete strip of the finished experience.
The vertical slice definition in agile software
In agile software, the same idea shows up as a thin vertical increment: a user story that touches every layer of the system, from interface to data, and delivers something usable. The Agile Alliance glossary describes this as slicing work so each increment runs through the whole stack rather than building one layer at a time. A horizontal slice, by contrast, finishes one layer (say, all the code) before any layer above it exists.
The vertical slice milestone in game development
Game studios adopted the term for a milestone: a short, polished segment proving the core loop is fun and the pipeline works. It usually includes final-quality art, sound, and UI for one encounter or mechanic, not a rough prototype. Our post on what a vertical slice is in game development covers the milestone in more depth.
The two meanings overlap because both demand the same thing: one feature taken all the way to done, across every discipline, instead of a lot of half-finished layers. That is also why tracking a slice is hard for a tiny crew spread across Trello, Discord, and Google Docs; the work crosses disciplines in ways scattered tools do not show. A shared board where each discipline sees the same slice, as we built into Inferno, exists precisely because of that gap.
Vertical slice vs horizontal slice: which should you build first?
A horizontal slice builds one layer across the whole game: all the art, or all the combat code, or all the audio pipeline. A vertical slice cuts through every discipline for one feature: one enemy that walks, attacks, takes damage, and dies, with sound and VFX attached.
| Horizontal slice | Vertical slice | |
|---|---|---|
| Scope | One layer, whole game | One feature, all layers |
| Example | Every enemy model finished | One enemy fully playable |
| First playable build | Late | Early |
| Risk surfaced | Integration, at the end | Design and tech, immediately |
What a horizontal slice looks like in a game build
Your artist spends three weeks producing every character model while code sits unmerged and audio is untouched. Nothing is playable, so nothing is testable. Scope creep hides inside layers because no one experiences the whole until the layers finally meet.
Why tiny crews usually benefit from vertical first
With 2-8 people, you cannot afford to discover in month three that the core loop is not fun. A vertical slice forces Design, Art, Code, and Audio to touch the same build early, which surfaces integration problems while they are still cheap to fix. It also gives you something shippable to show. The tradeoff: vertical first means some assets get rebuilt once the slice proves the direction, so budget for rework. Track that rework on a shared board like Inferno so the tiny crew sees which slice tasks are blocked across disciplines.
What does a vertical slice look like in an agile sprint?
In an agile sprint, a vertical slice is your sprint goal: one thin, playable increment that crosses every discipline. Instead of "finish all the enemy art" (a horizontal chunk), the sprint delivers "one enemy you can find, fight, and kill in a test level." That matches the agile principle of working software as the primary measure of progress, as stated in the Agile Manifesto principles.
One sprint, one playable increment
The slice becomes a single sprint goal on your board, with tasks branching under it: design doc for the encounter, enemy model and animation, hit detection and damage, one sound pass. Code, art, and audio all land inside the same two weeks, so you end the sprint with something you can actually run, not a pile of finished parts that don't assemble.
On a board like Inferno, that means one parent task for the slice with discipline-tagged tasks beside it. If your sprint ends and the slice doesn't run end to end, you overbuilt horizontally somewhere, and the board will show you exactly where.
How do you scope a vertical slice prototype without overbuilding?
The one-feature rule
Pick a single feature and a single level. If your slice covers two mechanics, you are shipping two slices and will finish neither. A combat slice, a traversal slice, a dialogue slice: one verb, proven end to end from input to on-screen feedback. Write the feature name at the top of the board and reject anything that does not serve it.
Placeholder assets are the point
Greybox geometry, programmer art, and stock sounds are not a compromise; they are the deliverable. Art polish before the loop is proven is scope creep wearing a work outfit. Your artist can start on final assets only for elements the slice proves are fun. If a system needs final art to feel good, that is a finding worth surfacing early, not a reason to wait.
Writing a definition of done for the slice
Before anyone touches code, agree on one sentence: "A player can [verb] in [level] and it reads in 30 seconds of play." Add a short exit list: build runs, no blocking bugs, the crew has played it. In Inferno, make that sentence the slice's description so every task traces back to it. When the sentence is true, the slice ships, even if the backlog still has ideas attached.
How do you break a vertical slice into tasks on a task board?
Slice by player-visible outcome, not by discipline. Each task should move the dash ability closer to something you can play, which is the same principle Jimmy Bogard applies to code: organize work around features rather than technical layers (Vertical Slices).
Worked example: slicing a dash ability
Take "the player can dash across a gap." Break it into tasks that each finish a piece of the slice:
- Design: write the dash rules (distance, cooldown, can it cancel?) in one page, linked to the slice.
- Code: implement dash movement, then cooldown, then gap-failure feedback.
- Art: dash trail VFX, character squash-and-stretch pose.
- Audio: dash whoosh, landing thud.
Mapping the slice to board columns
Run the slice across your kanban columns as a single swimlane: Backlog, In Progress, Review, Playtest, Done. Every task in the swimlane belongs to the same slice, so "Done" means the dash is playable, not that code finished while art is still a placeholder. The swimlane is your scope creep tripwire: anything that doesn't fit the dash outcome goes to the backlog, not the slice.
Keeping dependencies visible in a tiny crew
Order tasks so code lands first, art and audio attach to it, and playtest sits last. In a tiny crew where one person spans two disciplines, mark the handoff explicitly: "dash code done, art can start." If your board can't show that link, a comment naming the blocking task is enough. The failure mode you're avoiding is the 11 PM milestone surprise where a "fixed stuff" commit lands with no traceable task behind it.
When is vertical slice architecture worth adopting outside games?
Vertical slice architecture in C# in one paragraph
In the .NET world, "vertical slice architecture" means organizing your codebase by feature instead of by layer. Each slice holds its own controller, handler, validation, and data access, so adding a feature touches one folder rather than five. It pairs naturally with MediatR-style request handlers, and teams like it because a feature can be built, tested, and deleted without dragging half the codebase with it.
When it is overkill
If your app has fewer than a handful of features, or your team is one or two people, the classic layered structure is faster to work in and easier to hand off. Vertical slices pay off when features multiply and change independently. The same rule applies to your game: a tiny crew should slice one feature end-to-end first, then decide if the pattern earns its keep.
What are common mistakes teams make with their first vertical slice?
Scope creep disguised as 'just one more feature'
A slice is a prototype of shippable play, not a shippable product. Teams blur that line constantly: the grappling hook works, so now it needs a UI indicator, a sound, and three more levels. The distinction between a prototype and a minimum viable product matters here. A prototype answers a question, while an MVP is something you put in front of players (Atlassian's guide to MVPs). Your vertical slice is the first kind. Freeze the scope when the slice answers "does this core loop feel good?" For a wider view of this trap, see scope creep vs feature creep.
Slicing too thin or too thick
Too thin: "player can walk" is a task, not a slice, because nothing proves the loop. Too thick: "the entire first level playable" is a milestone wearing a slice costume. Aim for one complete mechanic touching every discipline.
Letting the slice live in five different tools
Design doc in Google Docs, art list in Trello, blockers in Discord. When your tiny crew can't see which audio asset blocks which build, dependencies rot silently and the slice stalls a week before the milestone.
How do you track a vertical slice end-to-end with a tiny crew?
One board per slice, one column per discipline
Give the vertical slice its own board, not a buried swimlane on the studio backlog. Columns map to disciplines: Design, Art, Code, Audio, plus a final Ship column that only accepts work when every card upstream is done. The slice is playable when the Ship column holds the milestone build, so "done" stays visible instead of living in someone's head or a Discord thread.
Where Inferno helps, and where it does not
Inferno keeps the slice's tasks and design docs in one shared workspace, so a tiny crew isn't reconstructing Friday night's broken build from scattered chat logs on Monday. Cards carry their discipline and their docs together, which makes scope creep obvious: if the slice grows a new column of cards, you see it before the milestone slips. Where it falls short: Inferno has no native engine integration and no build-status field, so you note which build a card landed in by hand. If your pipeline already auto-tracks builds elsewhere, that's duplicated effort. And a crew that lives entirely inside one tool like Codecks or HacknPlan may find switching costs outweigh the doc-plus-task pairing. Run the slice on one board for a sprint and judge from your own milestone, not from any tool's marketing.
FAQ
How long should a vertical slice take to build in a game jam or 48-hour event?
In a 48-hour jam, treat the slice as the whole deliverable: pick one mechanic, greybox it in the first few hours, and spend the remaining time making that single loop readable. There is no room for breadth. If your project has two mechanics by hour 24, cut one and polish the other to a shippable state.
Is a vertical slice the same as a playable prototype or an MVP?
No. A prototype answers one question cheaply, often with placeholder assets, and may be thrown away. An MVP goes in front of real players as something shippable. A vertical slice sits between them: prototype-grade in scope but final-quality in polish for one feature, proving the core loop and the pipeline at the same time.
Can one person build a vertical slice solo, or does it need every discipline?
One person can, and solo devs do it constantly, but discipline coverage still matters. The slice only proves the loop if design, art, code, and audio all exist at some level, even if that means stock sounds and programmer art. The difference is handoffs: solo, they happen in your head instead of on a board.
How many vertical slices should a small game have before production?
Usually one to three. The first slice proves the core loop is fun; a second confirms it holds up in a different context, such as a new enemy type or level beat. Beyond that, you are producing the game. If slice three still surprises you about the design, the concept needs more prototyping, not more slices.
Does vertical slice architecture replace layered architecture in C# projects?
Not automatically. For a small app or a one or two person team, layered code is faster to work in and easier to hand off. Vertical slices pay off once features multiply and change independently, because each feature lives in its own folder with its handler and data access. Migrate feature by feature rather than rewriting the whole codebase at once.