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. You need to be a workspace admin.

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.
• Code: the GitHub or GitLab repositories the team works on, and the base branch kanman should open pull requests against (usually main).
• A connection: the tracker must already be connected to your workspace. See Connect GitHub or Connect Jira and GitLab.
• CI: your existing CI keeps running on kanman’s pull requests. kanman waits for it as part of verification.
• Acceptance manifest (recommended): a .kanman/acceptance.json in the repository, so kanman can prove each outcome. You can add it later; see Add an acceptance manifest.

Start the setup

Open Teams and click New team, or press Ctrl+P (Cmd+P on Mac) and choose New team. 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 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 in the team settings.

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, Connect GitHub or GitLab takes you to Settings > Git and Connect Jira to Settings > Trackers. Your draft is kept while you connect, and Continue team setup on those pages brings you back.

Details and permissions:

• Connect GitHub
• Connect Jira and GitLab

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

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 for the next step.
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 Settings > Git.
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 in the team settings under Repositories.

Step 3: Columns

kanman uses six column roles. The setup reads your tracker’s status names and suggests a role for each (click Use suggested roles), which you confirm or change:

Exactly one status must be Ready, and at least one status each must be In progress, Review and Done. Several statuses can share the other roles. Boards with German status names are covered in Connect Jira and GitLab.

Step 4: Policy

Pick the preset the team starts with. Each card shows how many runs may work at the same time:

Whatever preset you pick, a new team starts with a run budget of 2.00 EUR, plan approval always (you approve every plan before code is written) and a human merge. Every preset except Autonomous denies infra/**, **/*.tf and .github/workflows/**; Autonomous denies only .github/workflows/**.

Every setting is described in Policy settings. Choosing between presets is covered in Choose and tune a preset.

Step 5: Executor

Choose the coding agent that writes the code: Claude Code or Codex. Then choose how compute is paid:

• 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 (Settings > AI providers). Claude Code works with Anthropic and Amazon Bedrock keys, Codex with OpenAI and Azure OpenAI keys.

The reviewer that checks the result runs on a different model vendor than the executor, so the same model never grades its own work. A fallback executor and the model per story size are set later in the team settings under Executor.

Step 6: 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 7: Dry run

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” or “Add a Demonstrate step”. 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.

Create the team

Click Create team. You land on the team page, for example app.kanman.ai/acme/teams/billing. The header shows Ready, 0 runs and the policy badge.

Next: Your first story.

Change the setup later

Everything from the setup lives in the team settings (Settings tab on the team page, /teams/<team>/settings/<section>):

Only workspace admins can change the settings; members see them read-only. Every change is recorded in the audit log.