Your first story

Your team is set up. Now pick one real piece of work and let kanman finish it. This page shows both ways in, what happens on the way, and what to do when kanman stops to ask.

Pick a good first story

The first story should build trust, not test limits. Good candidates:

• small (size S), in an area your team knows well
• with an outcome a person can see or call: a new API field, a filter, a validation message, a CSV column
• not touching infrastructure, migrations of production data, or security settings

Avoid broad refactors and anything that needs a decision from someone who is not in the room. kanman would stop and ask, which is correct but slow for a first run.

Way 1: Start from a requirement (in the conversation)

1. Open your workspace (it opens on the conversation with kanman) or press N anywhere. Check that your team is on the chip next to the message box.
2. Paste the requirement as you would write it to a colleague: a sentence, a paragraph from a spec, or a Slack thread copied as text. Press Enter.
3. kanman first decides what the message is. Only a work request becomes stories; a status question gets an answer, and an operational request (pause or resume the team, cancel a run, expedite or deprioritize a story) comes back as a card whose button names the change, for example Pause team; a paused team can be resumed from the same card with Resume team. Pausing and resuming need a workspace admin. If the requirement is too vague, kanman asks up to three questions first; answer them in the review and click Draft again.
4. For a work request, kanman drafts one or more stories, each with:
   • acceptance criteria in Given/When/Then
   • a test plan, a size (S, M, L) and the affected areas
   • the details kanman decided on its own (What I assumed) and the questions only you can answer, each marked Blocks approval or Doesn’t block
   • a readiness score from 0 to 100
5. The drafts arrive as a card. If a draft needs an answer, kanman says so in one sentence and lists the questions under it: Answer, Let kanman decide or Not relevant, or reply in the chat (“1: …, 2: not relevant”). See Answer kanman’s questions. Reject what you do not want and Approve the rest; Open review shows every detail to edit what is wrong. Only stories that pass every readiness check can be approved; owners and admins can also approve a story that only open questions hold back.
6. Click Write N stories in the card (or Write N stories to tracker in the review).

Approved stories are written to your tracker in one batch and carry the pickup label (kanman by default). They land in the Backlog column. Writing does not start the work: kanman tells you so in the conversation (“PU-43 is in the Backlog. Say "start" or move it to Ready and I’ll begin.”), and every written story in the card offers Start now. It moves the story to Ready exactly like dragging it, so you can also say “start PU-43” (or just “start it” right after writing). If you have several written stories, kanman asks which one you mean. On the Local plan runs are not included, so kanman explains that and links to Choose plan; when all run slots of the team are busy, the story still moves and waits for a free run slot.

Way 2: Start from an existing issue

If the issue is already written:

1. Add the pickup label (kanman by default) to the issue in GitHub, GitLab or Jira.
2. kanman mirrors the issue onto the team board, in the column of its status. The story page (/teams/<team>/stories/<KEY>) shows its readiness and lets you add missing acceptance criteria.

The acceptance criteria are what the independent reviewer checks the change against. See Stories and acceptance criteria.

Move the story to Ready

Click Start now on the written story in the conversation, say “start” and its key, drag the card to the Ready column in kanman (or use Move to on the card), or move the issue to the matching status in your tracker.

A story in Ready that is not assigned to a person is kanman’s to work. kanman notices the move right away, looks at the team’s whole board, plans the work (splitting it if it is too big for one change) and hands each piece to a helper. The helper works in its own sandbox on its own branch. See How a story flows.

Follow the run

The line above the message box says how many helpers are at work, for example Working on 1 thing; select it to see what each one is doing right now. In the conversation, the story’s live line changes in place: planned, in progress, checks running, in review, merged.

The run page (/teams/<team>/agents/<run-key>, in All tasks above the message box) shows what kanman is doing right now, the cost and the latest progress, see The run page. You can Stop the run at any time and Retry it later. To stop all of the team’s work at once, pause the team.

When kanman stops and asks

kanman finds out facts on its own: what CI says, what the code does, how your deployment works. It asks you only what it cannot find out: what you intend, a choice between options, or access it does not have.

Its questions for you are pinned at the bottom of the chat, over the message box, and the line above the message box says, for example, 1 story waits on people · 1 on you. Each question names the story, says why it matters and offers the options kanman sees; you can also answer in your own words, or in Slack or Microsoft Teams. kanman asks each question once and continues as soon as you answer. See Questions from kanman.

Some steps need a person to act, for example granting access. kanman then assigns the story to you with a note; write “@kanman done” in the notes when you are finished. See Handing work back and forth.

Review and merge

When the helper is done, kanman scans the change for credentials, pushes the branch and opens the pull request. Your CI runs on it, and a reviewer that did not write the change checks it against the acceptance criteria and looks for dropped or weakened tests. When CI is green and the reviewer approved the latest commit, kanman merges, and the story moves to Done. On a new team, the Setup card then completes.

If your team wants a person to approve every merge, require it in your code host’s branch protection; kanman waits for that approval like any colleague. See How kanman checks its work.

After the first story

• Let two or three more stories through before you change settings.
• Look at the cost of each run to calibrate the team’s daily budget.
• Ask kanman “why?” about anything it did; it answers from the team’s activity log.