Set up a team

A team is where kanman works with your engineers. It is bound to one tracker project and one or more repositories, and it has its own policy, budget and board. Most companies start with one team per product or service. This page walks through the setup.

Plan about 20 minutes for a typical repository. Owners, admins and members of the workspace can set up a team; viewers can’t, and kanman tells them who can. If something fails while the team is being created, nothing is left behind: your entries stay in the setup and you can try again.

Before you start

• Tracker: GitHub Issues of a repository, GitLab issues of a project, or a Jira project. kanman reads stories from it and writes approved stories back to it. You can also start without one: see Use kanman without a tracker.
• Code: the GitHub or GitLab repositories the team works on, and the base branch kanman should open pull requests against (usually main).
• A connection: you can connect GitHub, GitLab or Jira right in the first step of the setup. See Connect GitHub or Connect Jira and GitLab for the permissions.
• CI: your existing CI keeps running on kanman’s pull requests, and kanman judges every change by it. See How kanman checks its work.

Start the setup

Ask kanman in the conversation, for example “Set up a new team”, and kanman opens the setup. You can also choose New team in the chip under the message box, or type /new team in the message box and press Enter (Ctrl+Shift+B, Cmd+Shift+B on Mac, does the same). The setup lives at /teams/new/<step>, so every step has its own address and the browser’s back button moves between steps. It has these steps:

You don’t map columns yourself: kanman sets them up for you (see Columns). The team starts with the default limits and budgets, which fit a first team. You can go back to any step before you create the team. Your draft is kept while you move between steps. Everything can be changed later on the Team tab.

Step 1: Tracker

Pick the tracker connection the team mirrors. The list shows the tracker connections of the workspace and your own GitHub and GitLab connections.

To add one, use Add a connection below the list, without leaving the setup:

• GitHub or GitLab: Connect opens the provider’s sign-in in a small window. When you have authorized kanman, the window closes, the new connection appears in the list and is selected. If your browser blocks the window, Open in this tab runs the same sign-in in the current tab and brings you back to this step with everything you entered.
• Jira: Connect unfolds the Jira form right in the step (Jira Cloud with site, email and API token, or Jira Server / Data Center with a personal access token). After Save connection the connection is selected.

Providers that are already connected show as a connected chip. A self-managed GitLab with an access token is added once in Workspace settings > Connections.

Details and permissions:

• Connect GitHub
• Connect Jira and GitLab

Connections belong to the workspace, so a second team reuses them.

No tracker? Pick kanman board (no external tracker). It is listed even when the workspace has no connection, and the team’s stories then live on its own board. Repositories become optional, and developers can work with the stories from their own Claude Code. See Use kanman without a tracker and Use kanman from Claude Code or Codex.

Step 2: Project and repositories

1. Enter the Tracker project: for GitHub or GitLab issues the repository whose issues hold the stories, for Jira the project key. For Jira, kanman suggests the projects of your Jira; when you pick one, its workflow statuses become the team’s columns.
2. Check the Team name. kanman suggests one from the project, for example “Sandbox Team”.
3. If your tracker is Jira, choose the Code host: GitHub or GitLab (gitlab.com or your own GitLab server). With GitHub or GitLab issues, the code host is the tracker’s.
4. Add one or more repositories: pick them from the list of repositories your connection can reach, or type owner/name (on GitLab group/project, subgroups included) and press Enter. If your code host is not connected yet, a link takes you to Workspace settings > Connections.
5. Set the Base branch kanman opens pull requests against. The default is main.

Repositories you leave out are off limits. kanman checks this before every run and again on the final diff. You can add more repositories and branches later under Team > Repositories.

Step 3: Executor

Choose the coding tool that writes the code: Claude Code or Codex. Then choose how compute is paid. The choice starts with what your workspace set under New teams use in Workspace settings > Model access:

• Pay through kanman: usage is billed at cost plus 15 percent. No key needed.
• Use your own key: runs use a model provider key of your workspace. Pick it under Key, or add one with Manage keys (Workspace settings > Model access). Claude Code works with Anthropic and Amazon Bedrock keys, Codex with OpenAI and Azure OpenAI keys.

The reviewer that checks the result is a separate helper that did not write the change. The fallback is set later under Team > Models, Coding tool.

Step 4: Look (optional)

Pick a wallpaper from Unsplash and an icon. They show on the team page and on every run of the team, which helps when you run several teams. You can skip this step. See Personalize your team.

Step 5: Dry run

If your tracker has its own statuses (a Jira project), the step first shows Your columns: each status with the kanman column it reads as. Click Change to adjust it: this creates the team and opens its status mapping under Team > Repositories.

Click Run dry run. kanman reads up to three open issues that it would pick up (in the Ready status with the pickup label) and shows how it would size and refine them: a size, a readiness score and notes such as “Write Given/When/Then acceptance criteria”. Nothing is changed in your tracker or repositories.

Use the dry run to judge whether your issues are written in a way kanman can finish. If the readiness scores are low, read Write requirements kanman can finish before you start.

Columns

kanman works with six column roles:

How the team gets its columns:

• Without a tracker of its own statuses (kanman board, GitHub or GitLab issues): the team gets the six default columns, one per role.
• With a Jira project: its statuses become the columns, and kanman gives each one a role, first by its name (in English, German, French or Spanish, for example “Bereit” is Ready and “QS” is Review), then by its Jira status category. Statuses neither tells apart are judged by kanman’s model when your workspace has its own model key; otherwise they start in Backlog.
• If a role has no status, kanman adds its own column for it, at its place in the flow. For example, Jira’s “To Do, In Progress, Done” gets Ready and Review columns on kanman’s board. If several statuses would be Ready, the last one is Ready and the earlier ones are Refining.

The dry run shows the result. You can change it any time under Team > Repositories. Boards with German status names are covered in Connect Jira and GitLab.

Create the team

Click Create team. The new team’s board opens beside your conversation with kanman, for example app.kanman.ai/acme/teams/billing, with the team’s status in its header. With a tracker, kanman reads the project right away, so its stories arrive on the board within seconds.

At the top of your conversation, the pinned Setup card shows how far the team is: workspace, connection and team are done; first story, first run and the merged pull request follow. Its next step always has a button that takes you there (Describe it puts you in the message box to describe work, Pick a story highlights the Ready column). A team without repositories (kanman board with Claude Code) shows Claude Code connected instead of the first run and Done instead of merged. The Setup card is stored for the team, so everyone in the workspace sees the same progress in every browser; Hide removes it for everyone.

The last step of the setup lists Where you change this later: each choice of the setup and the page of the Team tab it lives on.

What kanman says first

kanman reads the team’s repositories and how the team works on its code host, with people’s work counted apart from kanman’s own, bots and scripts. Then it says what it found, once, in the team’s chat:

• In a team where people already merge their work, it describes the team instead of proposing work: the repositories, how often you merge and review, your releases, merge requests that have waited for weeks, and the conventions and tools it found (instruction files such as CLAUDE.md or AGENTS.md, your own commands, skills and tool repositories). It says how it will use each one and how you overturn that (“tell me if you’d rather …”). It proposes stories only when you ask.
• In a team where kanman does the work, it also proposes three small first stories you accept with one click.

If kanman’s account cannot reach some of the team’s repositories, it says which ones and what a workspace admin needs to do.

Next: Your first story.

Change the setup later

Everything from the setup lives on the Team tab in the team header (/teams/<team>/team/<section>): seven short pages in two groups in the list on the left. Every setting is one line with a short explanation, its current value and a Default mark; click it to open its editor in a side panel. Rarely used options sit under More options. Every change saves at once, with a Saved tick and Undo.

What kanman knows (memory, skills and the documents it may read) and the team’s services are on the team’s Mind tab under Memory, see Memory and skills. Working on the team’s stories from Claude Code or Codex is set up under Your settings > API tokens, see Use kanman from Claude Code or Codex.

Reviewing merge requests, maintenance, watching main, the weekly recap, the retro prompt, the daily update and answering mentions are built-in habits on the team’s Habits tab, changed in the chat. The rules for kanman’s own merge requests (a person’s approval before merge, asking a reviewer) are under Budget and limits.

The team is paused and resumed with the pause button next to its status line in the team header, not in the settings. Old links to pages that were merged still work and open the new page.

Only workspace admins can change the settings; members see them read-only. In Mind > Memory, members add and edit entries too. Every change is recorded in the audit log.