Teams

A team is the unit kanman works in. Each team is bound to one tracker project and one or more repositories, has its own policy and budget, and shows its work on a lean board. Most companies start with one team and add more as other engineering teams join (see Roll out to a second team).

Every team has its own chat with kanman, next to General, the conversation across all teams. Switch between them with the chip under the message box; it also starts a New team. Everything about a team, its runs, decisions, reports, incidents and setup, lands in that team’s chat, and a requirement for the team written in General moves there after you agree. See General and your team chats.

What belongs to a team

A team has a slug that appears in its URL, for example app.kanman.ai/acme/teams/sandbox-team, and a key prefix for its stories, for example SBX for SBX-12.

kanman as the team or for your team

Teams work with kanman in one of two ways, and a team admin (a workspace owner or admin, or the person who set up the team) chooses which in Settings > Team, card How I work with this team:

Under Who owns what you name ownership areas: a repository (or every repository of the team), optionally a folder such as services/billing, and its owner, kanman or a member of your workspace. A folder covers everything inside it, and each area has one owner. kanman builds in its own areas and leaves areas owned by a person to that person unless they ask. The cross on an area removes it; every change is saved at once and can be undone.

Below, Seen in recent changes shows who changed what most often in the team’s repositories, read from their merge requests about every hour. It is there so you can see who already works where before you name areas; kanman never changes it on its own.

Desktop Mobile

The board mirrors your tracker

Your tracker stays the source of truth. kanman does not ask anyone to move work out of GitHub, Jira or GitLab. It mirrors the issues of the connected project that are marked for kanman onto the team page and keeps them in sync in both directions:

• When someone creates, edits or moves a marked issue in the tracker, the team page follows, through the tracker’s webhooks and a regular sync every few minutes. Sync now in the Tracker card of Settings > Repositories and tracker starts one right away.
• If an issue loses its mark while it waits in Ready, kanman moves it back to Backlog. An issue deleted in the tracker disappears from the team page.
• When kanman writes approved stories, comments an evidence pack or moves a story after a gate passes, the change is written to the tracker and recorded in the audit log.

The team page is deliberately lean. It shows the columns and the story cards with their run status. When something needs attention, such as 1 run parked for repeated gate failure, it is a notice above the message box of the team’s chat (see Notices above the message box). The team opens beside its chat with kanman, which names the team, and its header stays on every page of the team: one row with the tabs Board, Runs, Reports and Settings and, at the right, a status such as Working · 1 running · 3 in review. On a phone the tabs are a bar at the bottom of the screen. New work is described in the team’s chat, not on the team page. See Tour of the app. You can move cards by dragging them or with the Move to menu.

Desktop Mobile

Watching kanman work

While the board is open, you see kanman work on it the way you would see a colleague in a shared document: its cursor, with the name tag kanman, does the work in front of you.

• Moving a story. kanman’s cursor picks up the card, drags it to its new column and drops it where it stays.
• Writing a story. The cards below make room, kanman types the title where the new card goes, and the card appears around it. Outcomes kanman proposes appear the same way.
• Making progress on an outcome. The cursor points at the outcome card’s progress dots while one of them fills.
• Moving a story on. When kanman’s work on a story reaches its next step (from Planning to Implementing, for example), the cursor points at the story’s status first, then the status changes under it.
• Deciding within its boundaries. When kanman approves its own plan in autonomous mode, and the request is on your screen in the team chat, kanman’s cursor clicks the option it chose, the way you would. The card then says “kanman chose …” and moves on to the next request.

Your own moves happen at once, and you always come first: as soon as you click, scroll or type on the board, kanman finishes its step instantly and shows everything that changed. When a lot happens at once, kanman plays the latest change and shows the rest right away, so the board is never more than a few seconds behind. When the tab is in the background or you chose reduced motion, changes appear without the cursor. The cursor never scrolls the chat for you: when the request is not on your screen, you simply see kanman’s answer. On a phone, kanman’s cursor works in the column you are looking at; changes in other columns simply appear there.

Column roles

kanman does not care what your columns are called. It cares what they mean. Every column of the tracker project is mapped to one of six roles:

German Jira boards work out of the box: Bereit, In Arbeit, QS and Fertig are recognized when you connect the project. You can change any mapping later in the team settings: the Tracker card shows each tracker status with an arrow to the kanman step it maps to, and beside it kanman’s steps with how many statuses lead there. A step that no status leads to carries a warning.

The roles are what make the workflow deterministic. kanman never guesses which column to use: the outcome gate moves a story from refining to ready, from in_progress to review, and from review to done, based only on these roles.

How a story gets picked up

A story is picked up when both conditions hold:

1. It is marked for kanman: it carries the pickup label (kanman by default) or is assigned to the account set under Settings > Repositories and tracker, Tracker card. The card also previews which issues would be picked up.
2. It sits in a column with the ready role.

Moving a card into Ready is all it takes. If the team requires acceptance specs, kanman first places the story in Refining and runs the Ready gate; the story moves on once its spec fails the way it should. kanman then checks whether the team is paused, inside its working hours, below its concurrency limit and within its daily and monthly budget. If so, it starts a run and shows its status on the card; if not, the story waits in Ready. Repository and path rules are checked during the run, and a violation lands in your decision inbox.

How many stories run at the same time is set by max_concurrency in the team policy and capped by the team’s plan. See Policies, presets and authority levels. When fewer of the team’s finished attempts are verified than usual (below the team’s own range of the last eight weeks), kanman takes one story at a time until the rate is back in that range, so it does not spend more on work that does not hold up. The audit log records when it slowed down and when it went back to the normal pace, and the weekly report says so.

Pausing a team

Admins can pause a team with the pause button next to the team’s status line in the team header. It takes effect at once, and Undo in the message takes it back. You can also ask kanman in the conversation, for example “pause the team until the token is rotated”; kanman shows the change on a card and pauses when you click Pause team. Pausing stops new runs; runs that are already in flight finish normally, and the team header shows Paused · Resume. To end the pause, click Resume in the header, or Resume team on the card in the conversation. Resuming lets kanman pick up Ready stories again. While the team is paused, Settings > Hours and rhythm says since when. Every pause and resume is recorded in the audit log.

Stopping all runs in an emergency

A pause lets running work finish. When something has to stop at once, for example a leaked token or a change that must not reach your repositories, owners and admins use Stop all runs under Workspace settings > Runs and runners. After you confirm, it acts on every team of the workspace, on kanman Cloud and on your own runners:

• every run that is working halts within a minute, and nothing it did is pushed;
• no pull or merge request is opened or merged, and no new run starts;
• runs that wait stay in the queue, and steps that wait for a runner are cancelled.

The stop does not wait for kanman or for a run to finish. The team header of every team shows Runs stopped, the chats show All runs are stopped at the top, and kanman says in General who stopped the runs. To end the stop, click Resume runs on the same card (or Resume in the message right after the stop). The halted runs then start again from their last pushed state, and new runs start as usual. Every stop and resume is recorded in the audit log.

kanman also stands down on its own when your git host or tracker does not answer: it holds new runs until the service is reachable again, and the team page says so in its health line.

The weekly report

Every Monday kanman sums up the team’s week under Reports (/teams/<team>/reports). The page opens with the latest week at a glance: stories shipped, merge rate, the time from Ready to the pull request and the spend, each with its change against the week before, a small trend of stories shipped per week, the team’s health and the top blocker. Below it, This week so far shows how work moves through the running week: runs in progress, in review and done, day by day. A week’s report adds the team’s health (merge rate, first-pass rate and gate pass rate as rings), the flow of work of that week and how the Ready to pull request and cycle times developed over the last weeks. Every chart has Show table for the numbers behind it. The report describes how the team delivers, never individual people. Stories closed without being delivered (covered by another story, duplicates, or ones the team will not do) are not counted as shipped; see Close a story without delivering it.

Under the delivery numbers, one sentence says how kanman served the team that week, measured against the team’s own history rather than a fixed target: how many finished attempts were verified (merged, main green, not reverted, checks passed) compared with the team’s usual range over the last eight weeks, how long it took until the first pull request or question, how many questions it asked per merged change, and how many attempts were blocked by infrastructure such as a provider limit or an outage. For example: “Service this week: 7 of 9 finished attempts verified (78 %, my usual 70-90 %), first result after 2.5 h, 1 attempt blocked by infrastructure.” Parts without data are left out. In a week in which kanman took one story at a time because the verified rate was below the usual range, the sentence ends with “I took one story at a time while the verified rate was below my usual band”. Like the rest of the report, it is about the team, never about a person.

A second sentence follows the week’s work from start to merge: how many stories came in, how many runs started, how many reached a merge request and how many were merged, and how many of the changes merged two weeks earlier are still green after 14 days. When the team kept retro notes that week (“retro note: …” in the team chat), the report lists them under Retro notes, without names.

Ask about the week in the team’s chat. “Which stories needed rework this week?” lists the stories that needed more than one attempt, with their keys, titles and attempts; “What did this week cost?” gives the week’s spend as the report states it, against the team’s budget when it has one. kanman answers from the team’s own numbers and adds the report’s card, so you can open the report from the answer.

When the reports of a new week are in, General says so the next time you open it (“The reports for week 40 are in: …”) with each team’s report card. Ask about the week in General to hear it for every team at once: “How did both teams do this week?” gives stories merged, rework and spend per team, “Why did rework go up?” the stories that needed rework in each team, and “Are we within budget?” a yes or no per team: against the team’s weekly budget (from its daily or monthly budget), or, when it only has a budget per run, whether a run of the week reached that limit, and what the week cost. Without any report yet, “Show me the weekly report” says so instead of asking which team you mean.

The report card in the conversation shows the stories merged, the rework rate, the cost per merged pull request (the week’s spend divided by the stories merged that week, the same figure as on the report page) and the time from Ready to the pull request. A week without a merged story shows no cost per merged pull request; kanman’s summary then says what the week spent.

To forward a report, open it and click Copy link. Anyone in your workspace who opens the link sees the same week. On a phone, Copy link opens the share sheet.

Once a team has a report, its status line in the team header shows the latest health, for example Healthy; click it to open that report.

Wallpaper and icon

Each team can have its own wallpaper from Unsplash and an icon. They appear on the team page, in the header of every run page and in the setup wizard, so people recognize a team at a glance. See Personalize your team.

Related

• Set up a team
• Stories and acceptance criteria
• Connect GitHub and Connect Jira and GitLab
• Policies, presets and authority levels