Roll out to a second team | kanman documentation

After the first team has merged a handful of pull requests, the next question is usually: which team is next, and what do we copy? This guide is a checklist for that step.

Is the first team ready to be the template?

Look at the first team’s last few weeks before you copy anything:

Signal	Where to look	Good sign
Changes pass checks early	Merge requests, activity log	CI green and the independent review approved on the first or second try
Questions get answered	Decisions > Stories	Few stories waiting long on people, short answer times
Cost is predictable	Cost meter, team report	Cost per merged pull request is stable
Reviewers trust the pull requests	Your code review	Review comments are about design, not about missing basics

If changes keep coming back from review or stories wait on people for days, fix that first. It is easier to tune one team than two.

What carries over, and what does not

Item	Scope	What to do
GitHub, GitLab and Jira connections	Workspace	Reused. Make sure the connected account can reach the new repositories.
Slack connection	Workspace	Reused. Pick a separate channel for the new team in its Team > Connections > Chats and choose with its chips what kanman posts there.
Members and roles	Workspace	Reused. Invite the new team’s engineers under Workspace settings > Members.
Webhooks	Workspace	Shared by every team.
API tokens	Personal, one workspace each	Work for every team of their workspace.
Self-hosted runners	Workspace	Shared by all teams. Check capacity before adding a team.
Budget and limits, hours	Team	Not copied. Each team starts on its own policy.
Memory and skills	Team	Not copied. Each team keeps its own; use Import from a repository for what a repository already says.

Step 1: Pick the team

The best second team:

has an engineering lead who wants it and will answer kanman’s questions
works in a repository with CI and tests
has a steady flow of small, well-described work

A team in the middle of a large migration or with no test coverage is a poor second candidate, even if it needs help most.

Step 2: Prepare the repository

Make sure CI runs on pull requests from kanman/* branches and that branch protection allows those pushes.

Step 3: Set up the team

Create the team with Set up a team. Then align the settings with what the first team learned, deliberately and not as a blind copy:

Denied paths: start from the first team’s list and add what is special about this repository, such as migrations or generated code.
Budget: start from the first team’s typical daily cost, plus a margin.
Merge approvals: if the new team wants a person to approve every merge at first, require it in the code host’s branch protection (see Merging).

The first team’s memory and skills are not copied, because each codebase has its own rules. What you can share:

the first team’s requirement examples from Write requirements kanman can finish
a short walkthrough: one person from the first team shows a merge request with its review and the activity log to the new team
the weekly team report of the first team, so the new lead knows what “good” looks like

Step 5: Watch the first two weeks

Read the review of each of the new team’s first ten merge requests.
Answer kanman’s questions quickly, so stories do not wait.
Compare cost and how often changes come back from review with the first team after two weeks. Large differences usually point to the repository’s CI or to how stories are written.

Billing and limits

Plans are per team, and each plan caps how many runs work in parallel (Starter 2, Team 5, Enterprise up to 20; Local runs nothing in the cloud). A new team starts with its own 14-day Team trial, and after that it needs its own plan; see Plans and billing. If both teams use self-hosted runners, add runner capacity before the second team starts.