Roll out to a second team | kanman documentation

After the first team has merged a handful of verified 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
Stories reach Review with proof	Evidence packs	Outcome proof present, criteria passed on the first or second attempt
Rework stays low	Run pages, team report	Most runs need no rework attempt
Decisions get answered	Decisions	Few decisions waiting long, 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 rework is high or decisions wait 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 under Settings > Slack, Team channels.
Members and roles	Workspace	Reused. Invite the new team’s engineers under Settings > Members.
API tokens and webhooks	Workspace	Shared by every team.
Self-hosted runners	Workspace	Shared by all teams. Check capacity before adding a team.
Policy, budgets, approvals, hours	Team	Not copied. Each team starts on its own policy.
Acceptance manifest	Repository	Each repository needs its own `.kanman/acceptance.json`.
Conventions	Team	Not copied. Each team learns from its own reviews.

Step 1: Pick the team

The best second team:

has an engineering lead who wants it and will answer decisions
works in a repository with CI and tests, ideally one that can be started with Docker Compose
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

Add the acceptance manifest, using the first team’s manifest as a pattern: Add an acceptance manifest.
Add .kanman/ to CODEOWNERS for the new team’s leads.
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.
Run budget: start from the first team’s typical cost per run, plus a margin.
Plan approval: keep always for the first week, even if the first team has moved on to by_size.
Preset: start the new team one step more careful than the first one is today.

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

the first team’s requirement and Demonstrate examples from Write requirements kanman can finish
a short walkthrough: one person from the first team shows a run page and an evidence pack 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 every evidence pack of the new team for the first ten stories.
Answer decisions quickly, so runs do not wait.
Compare rework and cost with the first team after two weeks. Large differences usually point to the manifest or to how stories are written.

Billing and limits

Plans are per team, and each plan caps how many runs work in parallel (Pilot 3, Team 5, Self-hosted 20; a team without a plan runs one at a time). Adding a team adds its own subscription; see Plans and billing. If both teams use self-hosted runners, add runner capacity before the second team starts.