How kanman orders a goal's stories | kanman documentation

An outcome with several stories is more than a list. One story adds a database column, the next builds an API on it, a third adds a button that calls the API. Done in the wrong order, or side by side in the same files, the work collides. kanman coordinates such stories the way an experienced lead developer would: it plans the outcome as a whole before the stories run, keeps the plan true while they run, and checks the whole once they are done.

A story that belongs to no outcome, or the only story of an outcome, needs none of this. It runs as usual, and kanman still keeps it out of files another run is changing (see Two runs never change the same files at once).

The outcome’s plan

Before the stories of an outcome start, kanman writes one plan for all of them:

The order: which story comes after which.
What the stories rely on. When one story provides something another one builds on, for example an export API the button calls, the plan states what exactly it provides. Both stories’ plans and their checks follow it.
What each story is expected to change: its repositories and files.

The plan of every story of the outcome builds on it, so each change fits the whole.

Nobody has to approve it. kanman writes the plan and its reasons into the activity log and goes ahead. If you disagree with the order, say so in the goal’s notes or the conversation, and kanman changes it.

What comes after what

A story that comes after another one shows it on its card with a quiet after SBX-12. It is not a warning; it disappears once SBX-12 has landed. The outcome’s own board lists its stories in the planned order.

A story never starts before what it comes after has landed. While it waits in Ready, its card says why:

Line on the card	What it means
Waiting for SBX-12 to land	It comes after SBX-12
Waiting for SBX-12 to land (same files)	SBX-12 is changing the same files right now
Waiting for SBX-12 to land (closely linked code)	Its code is so closely tied to SBX-12’s that the two go better one after the other

When a story lands, the stories that build on it get a short note at their next step about what changed, so they continue on the new state instead of an old one.

kanman never moves a story you placed yourself.

Two runs never change the same files at once

This holds for every story of a team, inside an outcome and across outcomes.

Before a run starts, kanman compares the files the story is expected to change with the files the team’s running stories are changing. When they overlap, the story waits with Waiting for SBX-12 to land (same files) and starts once SBX-12 has landed.
While a run works, it can turn out to need a file nobody expected. When it starts changing files another open run is changing, kanman pauses the later run at a safe point, keeps what it has done so far, and continues it on top of the other story’s work once that has landed. Its card says Waiting for SBX-12 to land (same files) in the meantime.

You do not have to resolve anything: the waiting run continues by itself. For the check kanman does on a single story right before its run starts, see Before a run starts.

The plan stays true

Plans meet reality. kanman updates the outcome’s plan, not just one story, when:

you add or change a requirement, a story or a criterion: in the chat, in a request, on the story or in your tracker;
a run brings news: a missing piece, a check that fails because of another story, a dependency nobody saw, a run touching files another story changes;
a story is split, moved to Later, closed, or cannot be delivered;
something lands that the remaining stories rely on.

kanman changes only the part that is affected. A story’s plan you already approved comes back to you only where it changed. A running story gets the change at its next step, or is paused when it would build on something that is no longer true.

kanman also keeps the plan calm. Work that is running or about to start is not moved around, and many small edits in a short time become one update instead of many: kanman collects them and updates the plan at most about every half hour, sooner only when that pays off for the outcome. Your own changes to the plan, a contradiction found in a requirement and a warning sign kanman set for the plan go through at once. While kanman collects, the outcome’s card says so, for example “I hold the plan steady since 10:12”.

Each change comes with one sentence on the outcome’s card, which stays there for a week. For example:

What happened	What the card says
A run found a missing piece	I added “Index on orders.status” before SBX-11: the export query scans the whole table
Two stories turned out to change the same file	I moved SBX-14 after SBX-12: both change src/db/schema.ts.
A story that others waited for was closed	SBX-12 was closed, so SBX-14 no longer waits for it.
A story was split	I split SBX-12 into SBX-15, SBX-16; the stories after it now wait for every part.
Something stories rely on changed	SBX-11 changed orders export API; I updated SBX-12 to the new contract.

The combined check

Each story is checked on its own before it merges. Once the last story of an outcome has landed, kanman also checks the combined result on the main branch against the outcome’s goal and success criteria. Stories that pass alone can still fail together.

When the combined check finds a gap, kanman files a story for it in the same outcome and plans it in. The card says, for example, The combined check on main found a gap in SBX-12; I added SBX-17 to fix it. When the check passes, the outcome is delivered and kanman writes its debrief.

Each story’s own step list

Inside a story, kanman works through the steps of the story’s plan, and the story’s checklist shows them. A step is ticked only when a check proved it. See Work in progress.