Teams | kanman documentation

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).

In the app, open Teams in the main navigation to see all teams of your workspace, or New team to set one up.

What belongs to a team

Part	What it is	Where to change it
Tracker project	The GitHub repository issues, Jira project or GitLab project kanman reads stories from and writes them to	Settings > Tracker on the team
Repositories	One or more GitHub or GitLab repositories kanman may change, each with the branches it may target	Settings > Repositories on the team
Column roles and pickup	How your tracker columns map to the six roles kanman understands, and which label marks an issue for kanman	Settings > Tracker on the team
Policy	Preset, denied paths, diff limits, plan approval, budgets, executor and more	Settings > Policy, Budgets, Approvals, Hours, Executor, Maintenance
Appearance	Wallpaper and icon	Settings > Appearance on the 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.

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 under Settings > 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, the story cards with their run status, and a header line such as Ready, 3 runs with the policy badge (for example Balanced) and, when something needs attention, a health line such as 1 run parked for repeated gate failure. The tabs Board, Intake, Runs, Conventions, Reports and Settings lead to the rest of the team. You can move cards by dragging them or with the Move to menu.

Screenshot coming soon Team page with wallpaper, the six columns, story cards with run status and the policy badge in the header

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:

Role	Meaning	Typical names
`backlog`	Filed, not refined yet	Backlog, To do
`refining`	Being refined: acceptance criteria, Demonstrate block and acceptance spec are being written	Refining, Refinement, Verfeinerung
`ready`	Ready for kanman to pick up	Ready, Bereit
`in_progress`	A run or a person is working on it	In Progress, In Arbeit, Doing
`review`	Verified and waiting for human review	Review, In Review, QS
`done`	Merged and finished	Done, Fertig, Closed

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 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:

It is marked for kanman: it carries the pickup label (kanman by default) or is assigned to the account set under Settings > Tracker. The settings page also previews which issues would be picked up.
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.

Pausing a team

Admins can pause a team under Settings > Hours with Pause kanman for this team, or by asking kanman on the team’s intake page, for example “pause the team”. Pausing stops new runs; runs that are already in flight finish normally, and the header shows Paused. Resuming lets kanman pick up Ready stories again. A pause through intake is recorded in the audit log as team_paused and team_resumed, a pause in the settings as policy_changed.

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.

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.