GitHub Projects as a kanban board: good for code, awkward for everyone else
If the question is whether GitHub has a kanban board built in, the answer is yes. GitHub Projects has a board layout, and a board is simply a view whose columns come from a single select field such as Status, or from an iteration field. Drag a card from one column to another and the field value on that issue or pull request changes to match. For a team whose work already lives in issues and pull requests, that is usually enough, and setting it up takes a few minutes.
The harder question comes later: what happens when people who never open a pull request need to use the same board. This article walks through the setup using the names GitHub uses on screen, lists the limits and automations as GitHub documents them (checked on October 8, 2026), and then looks at where mixed teams tend to split the work.
Setting up a GitHub kanban board, step by step
GitHub's own docs spread the setup across several pages. Here it is in one sequence.
1. Create the project and switch the view to Board
Create a project from your organization or user profile, then open the view menu and change the layout to Board. A Status field is the natural column field for a kanban board.
2. Choose the column field
Click View next to the search bar, then Column field, and pick the field you want. Any single select field or iteration field works. That second option matters: if the team plans in two-week cycles, an iteration field as the column field turns the board into a sprint board, with one column per iteration.
3. Add items
Use the "Add item" row at the bottom of a column to create an issue or a draft issue in place, or start typing "Add items" in the command palette to pull in existing issues and pull requests in bulk. When a view is grouped by a field, a new item created inside a group takes that group's value automatically.
4. Set column limits
Click the menu next to a column name, choose Set column limit, type a number and click Save. The count and the limit are shown at the top of the column, and the header is highlighted when the count goes over. This is the closest thing to a WIP limit.
5. Turn on the workflows
Open the project menu, click Workflows, and review the list under "Default workflows". Then enable the ones you need with Save and turn on workflow.
6. Shape the view
From the same View menu you can show and hide fields, slice by a field value (a side panel that filters the board to one value), sort, group into horizontal swimlanes, and show the sum of a number field at the top of each column. A number field for estimated hours plus a field sum gives each column a running total.
What the board can and cannot do
The feature set is solid for engineering work. The details below come from GitHub's documentation on customizing the board layout and related pages.
| Capability | How it works in GitHub Projects |
|---|---|
| Columns | Any single select or iteration field |
| WIP limit | Column limit is shown and highlighted, but it does not block adding cards, and automations can still add cards past it |
| Swimlanes | Group by a field. You cannot group by title, labels, reviewers or linked pull requests |
| Manual order in a column | Not available while the board is sorted |
| Fields per project | Up to 50, including built-in ones |
| Items per project | Up to 50,000, counting active views and the archive together |
| Other layouts | Table and roadmap, from the same data |
| Charts | Insights, built from project items |
Two rows deserve attention. First, the column limit is a signal, not a rule. GitHub states that setting a limit "does not restrict anyone from adding cards that would exceed the column's limit". Teams that rely on hard WIP limits to force a conversation will need a working agreement instead. Second, labels cannot be used for swimlanes. Many repositories carry their priority or area information in labels, so a team that wants priority lanes usually has to recreate that information as a single select field.
The 50,000 item ceiling is rarely a problem for one team. It becomes relevant when one organization-wide project collects every issue from many repositories for years. The auto-archive workflow exists for that reason.
Automations: what runs by default and what you have to switch on
GitHub's built-in workflows are the main reason developers like Projects. Two are on from the moment a project is created: when an issue or pull request in the project is closed, its status is set to Done, and when a pull request is merged, its status is set to Done. Nobody has to remember to drag the card.
Other workflows have to be enabled. You can set the status to Todo when an item is added, close an issue when its project status changes, archive items automatically, and add items automatically from a repository.
The auto-archive workflow accepts filters such as is:closed and updated:<@today-14d, so closed work that has been quiet for two weeks can drop off the board without being deleted. Archived items keep their custom field values and can be restored from the archive page.
The auto-add workflow is where the plan you are on starts to matter. GitHub documents the maximum number of auto-add workflows per project:
| GitHub plan | Auto-add workflows per project |
|---|---|
| GitHub Free | 1 |
| GitHub Pro | 5 |
| GitHub Team | 5 |
| GitHub Enterprise Cloud | 20 |
| GitHub Enterprise Server | 20 |
Each auto-add workflow targets one repository. On the free plan, a project that should collect issues from three repositories can auto-add from only one of them, and the rest have to be added by hand or through GitHub Actions and the GraphQL API. Note also that enabling auto-add does not pull in existing items. It only catches items that are created or updated after the workflow is on.
Where people outside engineering get stuck
None of the following is a defect. It is the result of a board that is built on top of issues and pull requests. It still shows up quickly once a designer, a marketer or a client joins.
Everyone needs a GitHub account, and organization projects have an entry rule
To work on an organization-level project, a person has to be invited, and GitHub only allows an individual invite if that person is already a member of the organization or an outside collaborator on at least one repository in it. For a client who only needs to see progress, that is a lot of setup. A project can be made public instead, but that shows the board to everyone on the internet, which is rarely what a client engagement wants.
Draft issues do not notify anyone
Draft issues are the easy way for a non-developer to add a card, because they do not need a repository. GitHub's documentation is explicit, though: people will not receive notifications when they are assigned to or mentioned in a draft issue unless it is converted to an issue. A project manager who assigns a draft to a designer and expects the designer to be pinged will be disappointed. To convert the draft, someone has to choose a repository, which brings the non-developer back into the code side of the organization.
The vocabulary is built for code
Cards are issues, pull requests or drafts. Labels and milestones belong to repositories. The default automations react to closing and merging. For work like "write the launch email" or "get legal sign-off", none of those words fit, and the board fills with drafts that never become issues.
Conversation lives somewhere else
Discussion happens in issue comments, which is fine for a bug. For a design review or a client decision, teams usually end up in a separate chat tool, and the decision never makes it back to the card.
How mixed teams usually split the work
Teams that have been through this tend to land on one of three arrangements.
One board, engineering rules. Everyone gets a GitHub account and learns to use issues. This works when the non-developers are few, technical, and in the same organization. It costs the least money and the most training.
Two boards, a handoff point. Engineering keeps GitHub Projects for issues, pull requests and sprints. Product, design and client-facing work moves to a separate board tool, and one card on each side links to the other at the handoff (for example, "design approved" becomes an issue). The cost is keeping two boards in step, which needs one owner.
One general board, links to GitHub. The whole team plans in a general-purpose project management tool, and engineering cards link out to the relevant pull requests. Developers lose the merge-to-Done automation unless they wire it up through an integration, so this suits teams where code is only part of the work.
| One GitHub board | Two boards | General board | |
|---|---|---|---|
| Who needs a GitHub account | Everyone | Engineering only | Engineering only |
| Merge sets card to Done | Yes | Yes, on the engineering board | Only with an integration |
| Client can see progress without repo access | Hard | Yes | Yes |
| Places to update | One | Two | One |
For a team comparing general board tools, the side by side pages for Trello and the rest of the comparisons list what each one includes on its free tier, which is the usual starting point for a small team.
When GitHub Projects is the right call anyway
It is easy to read the list above as a reason to leave. For many teams it is not. GitHub Projects is the right board when most cards are issues or pull requests, when the people moving cards are the people writing code, and when the default merge and close automations remove real manual work. It also costs nothing extra if the organization is already on GitHub, and the roadmap layout and insights cover a good share of what a dedicated tool would add.
It is also a reasonable choice for open source projects, where contributors already have GitHub accounts and a public project is the point rather than a problem.
The signals that it has stopped fitting are practical ones. Cards that stay as drafts for weeks. A second spreadsheet or board that someone keeps "for the business side". Status meetings where non-developers ask for updates that are already on the board, because they cannot see it. When two of those show up, it is worth trying one of the split arrangements above for a few weeks, before moving everything.
What to change first
Turn on the auto-archive workflow and add one column limit to the In progress column this week. If people outside engineering keep asking for status, move their work to a board they can open without a repository, and keep the handoff to one linked card per item. A team that wants every role on one board with kanban, Gantt and chat already included can start on Pinateca for free with up to 5 people.
Q1. Can GitHub Projects enforce a WIP limit on a column?
Not strictly. You can set a column limit, and the column header is highlighted when the count goes over it. GitHub's documentation states that the limit does not stop anyone from adding more cards, and automations can also push a column past its limit.
Q2. Why can I not group my board by labels?
GitHub Projects does not allow grouping by title, labels, reviewers or linked pull requests. The usual workaround is to create a single select field, such as Priority or Area, and group by that field instead.
Q3. How many repositories can feed one project automatically?
Each auto-add workflow targets one repository. GitHub Free allows 1 auto-add workflow per project, GitHub Pro and GitHub Team allow 5, and GitHub Enterprise Cloud and Enterprise Server allow 20. Items from other repositories can still be added by hand or with the API.
Q4. Can a client view the board without joining the organization?
For an organization-level project, an individual can only be invited if they are a member of the organization or an outside collaborator on at least one of its repositories. The other option is to make the project public, which exposes it to everyone on the internet.
Q5. Does assigning a draft issue notify the person?
No. GitHub notes that people are not notified when they are assigned to or mentioned in a draft issue until it is converted to a regular issue, and converting it requires choosing a repository.