GitHub Kanban Boards: Projects, Limits and Better Options

A GitHub kanban board is the Board layout in GitHub Projects. Columns are Status values, and cards are issues and pull requests from the repositories you add. Use it to see what is in progress on code you already track in GitHub. Skip it for intake, client work, forecasts, or any flow that starts outside a repository.

What a GitHub kanban board is

GitHub ships this as Projects, not a separate kanban product. Open a project at user, organization, or repository level, add a Board layout, and group by Status. The same items can sit in a table or a roadmap, and changing the status anywhere moves the card on the board.

Projects (classic) are retired, along with note cards that were not issues. Current boards are field-driven views over issues and pull requests.

A kanban board limits work in progress, shows blockers, and shows how long cards take to leave. GitHub gives you the columns and the drag and drop. The policies and measurements are yours.

What belongs on the board

Put work here only when it is, or will become, a GitHub issue or pull request.

A bug with a reproducing case belongs, as does a pull request in review or a spike that ends as an issue. A client catch-up, a checklist with no commit, or a sales follow-up pasted in so it would show up does not. That second kind turns the board into a junk drawer and makes the repository noisier.

How to set the board up

Create it under the organization when more than one repository feeds it. A repository project breaks the week a second repo joins the release.

1. Create a project with a Board layout, grouped by Status.
2. Rename Status to the states you use, four to six columns.
3. Add the repositories whose issues and pull requests should appear.
4. Turn on workflows that match the process: status moves when a pull request opens, and the item closes when it merges. Read each one, because a wrong auto-close hides unshipped work.
5. Add custom fields. Start with three.
6. Save a view for engineers ("my items, not Done") and one for a lead ("blocked, or In review too long").

Columns that match the work

Status	Entry rule	Exit rule
Backlog	Accepted, not started	Someone pulls it
Ready	Sized and unblocked	Work starts
In progress	One owner, work underway	PR opened, or review requested
In review	PR open, or design in review	Merged, or sent back
Done	Merged to the default branch, or closed with a reason	Archive on a schedule

Done means shipped or explicitly dropped. Merged to a feature branch is still In progress.

If nobody reviews, skip Review, since an empty column teaches people to ignore the board. Add Blocked only if every card gets a named owner and a next action the same day. Otherwise it becomes a parking lot.

Fields worth adding

Keep fields that change a decision:

• Priority, three values. Five collapse into two by week two.
• Size, in the unit you already use, for slicing work rather than performance reviews.
• Iteration, if you plan in weeks. Here an iteration is just a date window, with no sprint ceremony.

Filter by repository instead of keeping one board per repo. Leave theme and customer fields off unless someone uses them every week.

WIP is a policy you set. GitHub will not refuse another In progress card, so write the cap in the column description. Start at one item per person across In progress and In review, and change it when cycle time gets worse.

A worked example

Northwind is a sample team of six: four engineers, a designer, and a product manager, with repositories api and web. The numbers are for teaching.

They run one organization project, Delivery. Priority is Now, Next, or Later, iterations are two-week windows, and In progress caps at six. The designer has no status of her own. Her queue is an assignee filter, and design stays in Ready until the note is on the issue.

Mid-week, a web pull request has sat In review for two days, because opening it set that status. One card is stuck on a security question, so they move it to Ready, clear the assignee, and write the question on the issue. Friday ends with nine Done and three Ready cards that never started. Those three stay. There is no reviewed rollover, so the PM copies the titles into the iteration note and planning starts from the leftovers.

That GitHub kanban board works with one project, two repositories, few fields, a WIP cap checked by eye, and a weekly look at what stalled. It breaks when a second product, a support rotation, and a Slack-only contractor arrive together. The code stays visible, and the rest lives in threads.

Limits you will hit

These show up after the board looks fine.

Intake is an issue form. A Sentry error, a Slack line, or a client-call decision stays invisible until someone files it.

The unit of work is the issue or the pull request. A design note, two pull requests, and a docs change are four objects unless a tracking issue holds them, and those issues drift.

You can filter stale items, but you cannot reject a card past a column cap, and you get no cycle time percentiles or cumulative flow. Insights chart the project. They will not say what share finished inside a time box, or when a batch lands.

Workflows react to pull requests, reviews, and closes. A rule like "this ticket type skips QA" still lives in someone's head.

A meeting note or an on-call follow-up has no repository. If you file it, search gets noisy. If you leave it out, a spreadsheet becomes the real board. Projects also will not hold a loose note the way classic boards did.

Examples from software and ops teams show the gap: an engineering status field and a client-delivery board are different things.

Kanban for GitHub when the board is not enough

Kanban for GitHub can stay inside GitHub while three things hold: almost every card becomes a commit, the people moving cards already live in issues, and open pull requests answer "are we on track." Small teams stay for years, and a second tool costs time at every standup.

Move the system of record when work starts in chat, calls, or error trackers, when a cycle needs a reviewed handoff, when In progress is your forecast, or when ticket types need their own stages.

Jira is the usual next step for workflows, on-board WIP, and reporting, though it is heavier than six people need. Trello stays pleasant for one squad and thins out once the repository has to be the source of truth. Extra columns will not fix that. You need a path from request to shipped change: the card exists before the issue, stages match the work, and git history marks it done. See kanban flow for how cards should move in any tool.

A better fit for the whole delivery loop

Keep GitHub Projects as the code board. When requests, planning, and repositories have to agree, put the system of record somewhere else.

Falrow is built for that. Slack, client calls, and Sentry errors become tickets, each type with its own stages and triage. Cycles roll unfinished work after a review. The roadmap is a ticket count. Claude Code and Codex plan from the git repository using the team's workflow rules and version-checked writes, so the plan and the diff stay on the ticket. Granola notes, a file, or a paste become tickets only after a person reviews them. You also get cumulative flow, cycle time percentiles, and a Monte Carlo forecast from 2,000 runs, all on one self-hosted SQLite database. Falrow is in private beta, with access and pricing on request.

It is the wrong tool if all you want is columns on issues you already file. It fits when the GitHub board is accurate and the business still cannot see the work.

If you stay on GitHub, write down the WIP cap, define Done as merged or dropped, and review leftovers each iteration. Chat will stay untracked until someone turns it into an item.

How to decide this week

What share of In progress has a pull request or a commit from the last three days? How many items have sat in the same status since the last iteration? Which requests this week never became items? Where is the written rule that blocks a new card from entering a full column?

If most active cards moved, few are stuck, and this week's requests became items, keep the board and tighten the workflows. If requests die in Slack, or nobody can say when Ready clears, put a system in front of GitHub that creates the ticket first and lets the repository close it. Get the ticket and triage model right before you add another chart.

FAQ

Is GitHub Projects a real kanban board?

As a layout, yes: columns, drag and drop, filters, and items tied to issues and pull requests. It is not a full kanban system. You enforce WIP and aging, and you calculate flow. Teams that already file good issues often need nothing more.

What happened to GitHub Projects classic?

GitHub retired Projects (classic). New work belongs in Projects, which is a view over fields. Recreate your columns as Status options and turn on only the workflows you want. Some classic automations hid unfinished work, so do not copy them all on day one.

Can one board cover multiple repositories?

Yes. An organization project pulls in issues and pull requests from many repositories, and a standup can filter down to one codebase. One board per product beats one board per repository. Split when two products mean different things by In review, not just because a second repo appeared.

Should we leave GitHub for Jira or another tool?

Move when work no longer starts as issues, or when you need ticket types, reviewed rollover, and forecasts that insights do not give you. Stay if the same people own the board, the pull requests, and the conversation. Jira covers workflow and reporting for larger orgs. A workspace in front of GitHub covers the path from request to reviewed change without filing every note as an issue.