Your first week | kanman documentation

In the first hour you talked to kanman. In the first week you see it work with the team: it picks up stories, asks when it must, checks every change, and learns from every answer. By Friday you know where to look, what to expect and how to make kanman fit your team a little better.

Day 1: follow one story to the merge

Pick a story kanman works on (the line above the message box says Working on 1 thing) and follow it:

The story’s line in the team’s chat changes in place: written, working, waiting for an answer, delivered. Select the line under it to open the live work log.
When the work is done, your CI runs, then a review by a helper that did not write the change. Only when both pass does kanman merge. See How kanman checks its work.
A few minutes after the merge, kanman writes a short debrief: what was planned and done, what changed on the way, what it left for later. See Debriefs.

Try this in the chatIn your team's chat

Why did that story need a second attempt?
Show me what you changed and why.

Day 2: look at the board

Open the team’s Mind. The board shows what the team is working towards (outcomes) and the stories under them, calmly: a title and one quiet line per card, details when you point at it. Ask kanman instead of searching:

Try this in the chatIn your team's chat

Catch me up
What is blocked, and on whom?
Which stories wait on people?

See The board and Outcomes.

Day 3: hand work back and forth

kanman is a teammate, not a queue. When a step needs a person (a test account at a vendor, access, a choice between two designs), kanman assigns the story to that person and writes in its notes what is needed and why. It works the other way round too: write on any story, mention kanman and say what you want. It reads the whole thread and answers in it.

Try this in the chatIn a story's notes

@kanman take this over
@kanman split this in two
@kanman hold this until Monday

See Working with kanman.

Day 4: see what kanman knows about your team

kanman writes down what it learns as it works: decisions, conventions, who to ask, how each repository builds and tests. Open Mind > Memory to see every entry, where it came from and whether it is still true. Correct what is wrong, add what is missing with Add entry, or ask:

Try this in the chatIn your team's chat

What do you know about how we release?
How does the billing service build and test?

When kanman does the same kind of work twice, it turns what it did into a skill, so the next time it follows the steps instead of searching again. See Memory and skills.

Day 5: start your first team habit

By now you have probably asked kanman the same thing twice. That is a habit waiting to happen. Open the team’s Habits tab to see what kanman already does on its own (reviewing merge requests, watching main, keeping dependencies current), then tell it what else it should keep doing:

Try this in the chatIn your team's chat

Every Friday at 15:00, post what we shipped this week
Every Monday at 9:00, tell us which merge requests have waited longest for review

kanman answers with a habit card. Start it, and the habit appears on the Habits tab with every run it makes.

New habit

Waiting for review

When: Mondays 9:00
What: The merge requests that have waited longest for review, oldest first
Where: Team chat
May do: Nothing outside kanman
Budget: From the team budget

More ideas: Habit ideas to copy.

What to expect from kanman

It asks once, in one place. Questions it can answer itself (by trying, looking it up or running a check) it never asks you.
It says what it did on its own, with a way to overturn it.
It stays inside the team’s rules. Repositories, branches, budgets and what it may do in each connected system are set by the team, and enforced outside the model. See Limits and rules.
It tells you when something goes wrong, and what it does about it.

Where next

Make it yours with habits: what kanman can keep doing for your team, and for you.
Connect your tools: code host, tracker, chat, alerts and wikis.