Phase 4 — Implementation

The first three phases decided what to build and how. Implementation is where the product actually gets written — not in one heroic push, but one story at a time, in a tight, repeatable loop. This is the phase you'll spend most of your time in, so it pays to know the rhythm cold.

By now Solutioning has left you two things: an architecture spine (the invariants every story must respect) and an epics & stories list (the work, broken into shippable slices). Implementation turns that list into working code, one slice at a time, with your hybrid team — you and your AI coding agents — moving each story from an idea to Done.

The heart of the method: everything before this phase exists to make the story cycle below run smoothly. If you learn one loop by heart, learn this one.

Start with a sprint plan

Before the first story is written, you lay out the running order. Sprint Planning reads your epics and stories and produces the plan the implementation agents will follow, in sequence, for every story.

Run it with:

/bmad-sprint-planning

Its output is a single file, sprint-status.yaml, written to _bmad-output/implementation-artifacts/. Think of it as the flight plan: it lists every story, the order to build them in, and where each one currently stands. The Stories view in BMAD Board reads this file to draw your board, and the story cycle updates it as work moves.

Note: Sprint Planning is the one required kickoff step of Phase 4. You run it once to open the sprint; you don't re-run it for every story.

Check progress anytime

You never have to guess where the sprint stands. Sprint Status summarizes it and points you at the next thing to do:

/bmad-sprint-status

Run it whenever you sit down, after a break, or when you've lost the thread. It reads sprint-status.yaml, tells you what's done, what's in flight, and what's next, and routes you to the right command. It changes nothing — it's a read.

The story cycle

With a sprint plan in place, each story flows through the same three-step loop. This is the engine of BMAD.

1. Create Story

Create Story prepares the next story in the sprint plan — or a specific one you name — as a self-contained spec file:

/bmad-create-story

The output is a story file in _bmad-output/implementation-artifacts/ (for example, story-flow-1-2-playbook-component.md). This file is the whole point: it carries all the context the dev agent needs — the acceptance criteria, the relevant architecture invariants, the files in play — so the agent implementing it doesn't have to reconstruct the plan from scratch. Implement from the story spec file, not from memory.

Validate Story (optional readiness check)

Before you hand a fresh story to the dev agent, you can run an optional readiness check. It validates the story's completeness — are the acceptance criteria clear, is the context sufficient — and reports gaps before development begins:

/bmad-create-story validate

It's the same skill (bmad-create-story) in its validate mode. Skip it for routine stories; reach for it when a story is large, ambiguous, or high-risk. A few minutes here can save an hour of a dev agent building the wrong thing.

2. Dev Story

Dev Story is where code gets written. The agent reads the story spec, implements the tasks, and writes the tests:

/bmad-dev-story

This is your Senior Software Engineer, Amelia 💻, at work: red, green, refactor — tests first, 100% passing before anything moves to review. When Dev Story finishes, it hands off to Code Review.

3. Code Review

Code Review inspects the change adversarially — walking edge cases and auditing the work against the story's acceptance criteria:

/bmad-code-review

Code Review has exactly two outcomes:

Issues found → loop straight back to Dev Story to fix them, then review again. This is the In-Progress ↔ Review loop, and a story may go around it more than once.
Approved → the story is Done. Move to the next Create Story, or, if that was the last story in the epic, run the Retrospective.

Tip: The loop is a feature, not a failure. A story that bounces between Dev Story and Code Review a couple of times is the method doing its job — catching problems while they're small.

How the cycle maps to the board

In BMAD Board, each story advances through five phases. Clicking a phase on a story card launches the matching BMAD command in the embedded terminal — you don't type the command yourself, the board fills it in.

Phase	Icon	Meaning	Command launched	Session
Backlog	○	Create the story spec	`/bmad-create-story`	resumes prior
Ready	◐	Start developing	`/bmad-dev-story`	resumes prior
In Progress	◑	Continue development	`/bmad-dev-story`	fresh session
Review	◕	Run code review	`/bmad-code-review`	fresh session
Done	●	Story complete	—	—

Two details worth internalizing:

The In-Progress ↔ Review loop. In Progress and Review are the two halves of the same loop. A story cycles between them — dev, review, dev again — until Code Review approves it and it lands on Done.
Fresh session vs. auto-resume. Clicking Backlog or Ready auto-resumes the story's prior session, so the agent picks up where it left off. Clicking In Progress or Review deliberately starts a fresh session instead — no auto-resume. Each pass through the loop gets a clean slate, so a review isn't biased by the dev conversation that produced the code, and a re-dev isn't anchored to a stale plan.

Note: BMAD Board no longer renders a kanban board with lane columns. A story's status is a phase it advances through, shown on the story card — not a column you drag it between.

Closing an epic

When the last story in an epic reaches Done, take a beat before the next epic.

Retrospective

Retrospective reviews the completed epic — what shipped, what was learned, what to carry forward — and recommends the next epic (or, if something's seriously off, a course correction):

/bmad-retrospective

It's optional but strongly encouraged at every epic close-out. Its output lands in _bmad-output/implementation-artifacts/. This is how the method compounds: each epic gets a little smoother because the last one was examined honestly.

When a sprint needs to change course

Sometimes reality intervenes mid-sprint — a requirement was wrong, an assumption broke, priorities shifted. Don't force the plan. Run:

/bmad-correct-course

Correct Course navigates significant changes. It can recommend anything from a small edit to the epics and stories, up to redoing sprint planning, revisiting the architecture, or updating the PRD. Use it when a story-level fix isn't enough and the plan itself needs to move.

Running it in BMAD Board

You can drive this entire phase from the app:

Sprint Planning once, to open the sprint and write sprint-status.yaml.
For each story, click its phase on the story card — Backlog to create it, Ready / In Progress to develop, Review to review — and the board launches the right /bmad-* command in the terminal for your chosen provider.
Each story develops in isolation on its own git worktree, so parallel work never steps on itself. See Documents, git & history for how worktrees keep each story's branch clean.
Run Sprint Status whenever you want a read on where things stand.

That's implementation: a sprint plan, then the same three-step cycle repeated until the epic is done — the loop that turns a stack of stories into a shipped product.

Next steps

Quality & testing — how the TEA quality gate and test strategy sit alongside the story cycle.