GitHub Projects as a Kanban Board: Setup and Limits

GitHub Projects makes a good kanban board when your work is already issues and pull requests. Create a project, choose the Board layout, use the Status field as the columns, turn on the built-in workflows so closed issues and merged pull requests move to Done by themselves, and add an auto-add workflow so new issues arrive without anyone dragging them in. Column limits exist, but they only highlight a full column; they do not stop anyone. Where it stops is at the edge of GitHub: everyone who works the board needs a GitHub account, and the board shows GitHub items, not the rest of the work.

Everything below comes from GitHub’s own documentation as it stands at the end of September 2026. GitHub changes Projects often, so check the linked pages before you rely on a detail. If you want the basics of the method first, what a kanban board is covers them.

Step 1: create the project

Projects live on your profile or on an organisation, not inside one repository, so a single board can hold issues from several repositories. From the Projects tab choose New project, then start from scratch with Table, Roadmap or Board, or pick a template. GitHub’s quickstart for Projects↗ (opens in a new tab) walks through the same steps and shows how to import items from a repository as you create it.

A project holds three kinds of item: issues, pull requests and draft issues. Draft issues exist only in the project, which makes them handy for a rough idea you are not ready to file, and you can convert one into a real issue later. The documented ceiling is 50,000 items per project, counting the archive, which few small teams will meet.

Step 2: choose the board layout and its columns

A project can have several views, each with its own layout: table, board or roadmap. On a board view, the columns come from one field. GitHub’s board layout guide↗ (opens in a new tab) says you can set the column field to Status for a kanban board, or to any other single select or iteration field. Dragging a card to another column changes that field’s value on the item.

So the columns are simply the options of the Status field. Edit them in the field settings to match the stages your work passes through. A single select field can hold up to 50 options, far more than a readable board needs. A practical starting set for a small software team:

• Backlog: filed, not yet agreed.
• Ready: agreed, small enough to start, and nobody has started it.
• In progress: someone is working on it.
• In review: a pull request is open and waiting for a reviewer.
• Done: closed or merged. Keep this name, because the default workflows below set Status to Done.

The same view settings also offer Group by, which gives you horizontal sections similar to swimlanes; Slice by, a side panel that filters the view to one field value; sorting; and field sums, which total a number field per column. One trap: once a board view is sorted, you can no longer reorder cards by hand within a column. If the order of Ready is your priority list, leave that view unsorted.

Step 3: set column limits, knowing what they do

Kanban asks you to control how much work is in progress, and GitHub Projects has a column limit for that. Open the menu on a column, set a number, and the count shows against it. What it does not do matters as much: GitHub states that a limit does not stop anyone from adding cards beyond it, and does not stop automations either. The column is simply highlighted once the count goes over.

That makes the limit a signal, not a gate. It works if the team agrees what happens when In progress turns red, usually that nobody starts anything new until something moves on. Write that rule down where the whole team will see it, so it is not only in one person’s head.

Step 4: turn on the built-in workflows

Projects has built-in workflows under the project’s Workflows menu. Two are on by default: when an issue or pull request is closed, its Status is set to Done, and when a pull request is merged, its Status is set to Done. Others archive items automatically and add items automatically.

Auto-add is the one that makes a board trustworthy, because otherwise new issues exist in the repository and never reach the board. You give it a repository and a filter, and matching items are added when they are created or updated. Two details from GitHub’s auto-add documentation↗ (opens in a new tab): enabling it does not sweep in existing items, so add those once by hand; and the number of auto-add workflows depends on the plan, one on GitHub Free, five on Pro and Team, twenty on Enterprise Cloud and Enterprise Server. The filter supports only a few qualifiers, such as is, label, reason, assignee and no.

is:issue is:open -label:wontfix

Pair it with auto-archive, which uses an updated filter to clear items out of the views once they have gone quiet. Archived items keep their context in the project and can be restored from the Archived items list.

Step 5: iterations and the roadmap, if you want them

An iteration field adds time-boxes to a kanban board without turning it into a sprint process. You choose a length in days or weeks and a start date, GitHub creates three iterations to begin with, and you can insert breaks for holidays. In filters, @current, @next and @previous pick out iterations relative to today, so a board view filtered to iteration:@current shows only this cycle’s work. GitHub’s iteration field page↗ (opens in a new tab) lists the operators.

The roadmap layout is a timeline built from date and iteration fields. Pick a start field and a target field, zoom to a month, quarter or year, and drag bars to change dates. Markers can show iterations and milestones. It is useful for telling people outside the team roughly when something lands; it adds nothing to the day-to-day flow, so treat it as a second view on the same items rather than a second board.

The honest limits

• Everyone needs a GitHub account. Access is managed per project with No access, Read, Write and Admin roles for organisation members and collaborators. A client, a site manager or a tester who is not on GitHub has no way in.
• Public means public. A public project can be seen by anyone on the internet, although GitHub’s visibility rules↗ (opens in a new tab) keep items from a private repository hidden from people without access to it.
• Column limits are advisory. Nothing enforces them, so the discipline is the team’s.
• Charts are about counts, not flow. Insights offers current and historical charts, including a burn-up; GitHub’s insights documentation describes no cumulative flow diagram or cycle-time chart, so those numbers are yours to work out.
• Only GitHub items. Work that is not an issue or pull request, a marketing brief or a supplier chase, becomes a draft issue that nobody outside the project sees.
• An AI assistant usually acts as you. GitHub’s official MCP server has a Projects toolset, off by default, and it works through a personal access token; Claude and the GitHub MCP server covers the set-up. Changes made that way carry your name.

When GitHub Projects fits

It fits well when the people doing the work and the people watching it are all on GitHub, and when the work is code. The board then moves itself: an issue closes, the card goes to Done; a pull request merges, the card goes to Done. No other tool gets that closer to the repository, and there is nothing new for anyone to learn. For a small development team, that alone usually settles it.

It fits less well when the board has to serve people who will never open GitHub, when you want a separate identity and a narrower role for an AI assistant, or when half the work is not code. In those cases many teams keep GitHub Projects for engineering and a second board for everyone else, with the issue number recorded on the task.

The same board on fenbs, for comparison

fenbs makes the opposite trade. Its lanes are fixed at four, To Do, Next Up, In Progress and Completed, and you cannot add a review column or set a column limit, so a limit is a team agreement you check by counting In Progress. It has no iterations, no roadmap view and no automations tied to pull requests. What it adds is people and AI assistants as members with roles: a client or tester joins by email with a role such as Client or Reporter, an assistant connects over MCP, and History records every change with who made it. Each task is a feature, enhancement or bug with a priority from 1 to 10, and the “Your reference” field can hold the GitHub issue number. fenbs vs GitHub Projects sets out where each is better.