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 limits 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 Personal, 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 Personal moves there after you agree. See Personal and your team chats.

Team members

Everyone in your workspace can see every team: its board, its chat, its runs and its reports. Belonging to a team is one step more. The members of a team are the people kanman works with there:

• they get the team’s questions, decisions, pings and updates (each at the level they choose, see Your level per team);
• they answer the team’s decisions;
• kanman takes instructions from them in the team’s chat.

Leads are members who also configure the team like an admin: its settings, who belongs to it and who may join. The person who set up the team is its first lead. Workspace owners and admins can configure every team, but they get a team’s questions only when they are members. A manager who oversees several teams joins them with the level Updates only, no questions.

Joining. A team is open by default: open it and click Join (in the team’s chat, in the team switcher or under Team > Team, line People). A lead can switch the team to Only via a lead or invitation; then a lead adds people. Everyone can leave a team on the same card.

Managing members. In Team > Team, line People, leads add colleagues of the workspace, make a member lead or remove someone. An invitation can name the teams a new colleague joins as a member and the teams they lead; they belong to them from their first day (see Invite people). Viewers read every team but join none.

Reading along. People who are not members can still write in a team’s chat, and the team sees what they write, but kanman does not act on it as an instruction. Their message box says Join to work with kanman here.

Finding your teams. Wherever teams are listed, in the team switcher under the message box and on the teams page, My teams come first. Every other team is under All teams, folded away, with a search field.

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 Team > Team, line 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 line of Team > Repositories 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 on an issue or moves a story, the change is written to the tracker and recorded in the activity log.

The team page is deliberately lean. It shows the columns and the story cards with their run status. When something needs attention, 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 Mind (with the board), Habits (what kanman keeps doing on its own), Stories (the running week and its success stories) and Team (the team’s 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.

The board is calm on purpose: each story card shows its title and one quiet line under it with the key, how far its checklist is (2/5), its notes and who works on it. Only what needs a person gets a line of its own, such as what blocks a story, and while kanman works on a story, what it does right now. Point at a card, or move to it with the keyboard, to see its short description, labels and kanman’s latest step beside it; the story page has everything. The Move to button appears when you point at a card (on a phone it is always there).

Done and columns without cards are slim rails with their name and count, so the columns with work fit side by side. Select a rail to open the column, and the fold button in its header to make it a rail again. While you drag a card, a rail opens as you reach it, and a column that gets a card opens by itself.

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.
• Finishing a story. The cursor carries the card onto the Done rail, where it folds in and the count goes up.
• Making progress on an outcome. The cursor points at the outcome card’s progress bar while it 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.

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 under Team > Repositories: the Tracker line 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: it moves stories between columns 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 Team > Repositories, line Tracker. 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. kanman notices the move, looks at the whole board and starts the story when it fits the plan: unless the team is paused, the daily budget is used up, or the story is assigned to a person. See How a story flows.

kanman decides how many stories it works on side by side, and in which order, from what is on the board: stories that touch the same files wait for each other, and urgent work goes first.

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 work; what is already in flight finishes 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, Team > Hours 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 Personal 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

When kanman finishes a story or a rollout, it tells you in the team chat, like a coworker would: what it achieved and why that matters for you or your customers, with the proof underneath (merges and repositories, approved reviews, the browser proof to play, and links to the story and to the Stories tab). The Friday recap appears in the team chat too. In Personal, each of these names its team.

The team’s Stories tab (/teams/<team>/stories) always shows the running week, from Monday until now. It opens with the week in kanman’s own words: every Friday afternoon (15:00 in your workspace’s time zone) kanman writes a short recap like a teammate would, covering what it achieved and why that is good for you, what comes next and what it needs from whom. It stays at the top as “This week, in kanman’s words” until the next one; before the first recap, kanman’s latest success story leads. Then comes the week at a glance: the merges and the repositories they touched, with a bar per day, the stories moved to Done, the reviews approved and the objections they raised, the pipelines that turned red after a merge and how many are green again, and the questions waiting on people. Under it, an activity timeline shows kanman’s work over the last year (half a year on a phone), one square per day: hover over or move to a day to read its merges, reviews and browser proofs. Then come the week’s success stories: one card per story kanman told, however many repositories it touched, so a change rolled out to 237 connectors is one story. Each card says in kanman’s words what it achieved and why it matters, and shows the proof: merges and repositories, reviews and the objections they caught, whether the main branch stayed green after the merges, the time from the first to the last merge, the browser proof (play it right from the card) and who was involved. The biggest story of the week leads. The rest of the week’s work follows as a short list under Other work this week, one line per story. Last comes Watch: what is still open now, such as a pipeline still red after a merge or an objection nobody resolved. Stored weekly reports still open at their own links (/teams/<team>/stories/weeks/<week>). 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, Personal 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 Personal 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
• Limits and rules