GitHub Projects as a kanban board: good for code, awkward for everyone else
The code already lives on GitHub, the issues are already there, and GitHub Projects comes with the account. Turning on a board layout takes a minute. For a development team, that is a strong argument for searching "github kanban board" and stopping there.
The trouble usually starts a few weeks later, when the designer, the account manager or the client needs to see the same work. A board built around issues and pull requests fits developers very well. It fits other people less well, and the friction shows up in small, repeated ways. This article covers what GitHub Projects does, where it shines, where it strains, and how teams with mixed roles tend to split the load.
What GitHub Projects actually gives you
GitHub Projects is the planning layer that sits on top of issues and pull requests. The GitHub documentation on Projects describes three layouts:
- Table, a spreadsheet of items with sortable, filterable columns.
- Board, the kanban view, with columns driven by a single select field such as Status.
- Roadmap, a timeline that places items using date or iteration fields.
Each project can hold up to 50 fields, including built-in ones. Custom field types include text, number, date, single select and iteration. Iteration fields let a team plan in fixed cycles, such as two-week sprints, with breaks between them.
Items can be issues, pull requests, or draft issues. Draft issues exist only inside the project until someone converts them into real issues in a repository, which is handy for rough ideas that are not ready to become tickets.
GitHub has also raised the size ceiling. Projects that were once capped at 1,200 items can now hold up to 50,000 items, a change GitHub announced in its changelog in 2025.
Built-in automation
Projects include built-in workflows that set fields when something happens. A common setup marks an item Done when its issue is closed or its pull request is merged, and archives items automatically once they match a rule. For anything beyond that, GitHub Actions and the GraphQL API can update project fields.
Dependencies
Issues now support "blocked by" and "blocking" relationships. According to the GitHub changelog entry on issue dependencies, the feature is available on Free, Pro, Team and Enterprise Cloud plans, and blocked issues show a Blocked icon on project boards.
Where it works well
For work that is mostly code, GitHub Projects is hard to beat on convenience.
The board updates itself
When a pull request that closes an issue is merged, the issue closes and the built-in workflow can move the card to Done. Nobody has to remember to drag it. On a code-heavy team, that removes a large share of the manual upkeep that makes other boards go stale.
One place for context
The card is the issue. Its discussion, linked pull requests, commits and review status are all one click away. Developers do not need to copy links between a tracker and a repository, and nothing drifts out of sync.
Views are cheap
A project can have many saved views: a board for the current sprint, a table filtered to one label, a roadmap for the quarter. Views are quick to create and share by URL, so different people can look at the same items in the way that suits them.
It costs nothing extra
Projects is included on the Free plan. For an open source maintainer or a small development team already using GitHub, there is no second subscription and no second sign-in.
Where it gets awkward for everyone else
The same design choices that make GitHub Projects smooth for developers create friction for people whose work is not code.
Every person needs a GitHub account and access
Anyone who edits the board needs a GitHub account and permission on the organization or repository. For a client, a freelance copywriter or a finance colleague, that is an extra account on a site built for software. On paid organization plans, members also count as seats; the Team plan is listed at $4 per user per month on the GitHub pricing page.
Tasks are shaped like issues
An issue has a title, a Markdown body, labels, assignees and a repository. That fits a bug or a feature. It fits less naturally for "approve banner copy", "book venue for launch" or "send invoice", which have no repository and no pull request. Teams end up creating a catch-all repository just to hold non-code issues, or leaving them as draft issues that never quite become first-class items.
Conversation stays inside each issue
Comments live on the issue. There is no team chat alongside the board, so quick coordination drifts to Slack, email or a messaging app. The decision then lives somewhere the board cannot show.
The timeline is a planning view, not a schedule
The roadmap layout places items on a timeline from date or iteration fields, and it can show markers for iterations and milestones. Dragging an item changes its dates. The roadmap documentation does not describe drawing dependency lines between bars, so for a launch plan where marketing, legal and engineering tasks chain together, teams often keep a separate schedule.
Calendars and fixed slots are missing
There is no month calendar layout and no shift or timetable style view. Content calendars, event schedules and staff rotas need another tool.
Comparing the fit by role
The table below summarises how the core needs of different roles line up with what GitHub Projects provides today.
| Need | Developers | Designers and PMs | Clients and non-technical staff |
|---|---|---|---|
| Board that updates from code activity | Strong fit | Useful to read | Rarely relevant |
| Account and access | Already on GitHub | Usually fine | Extra account needed |
| Tasks with no repository | Rare | Common | Most tasks |
| Team chat next to tasks | Comments on issues | Often wanted | Expected |
| Timeline with task chains | Roadmap by dates | Often wanted | Often wanted |
| Month calendar | Rarely needed | Sometimes | Often needed |
None of this is a flaw in GitHub Projects. It is a tool designed around software work, and it does that job well. The question is only how much of your team's work is software work.
Getting the most out of it on a code team
If most of the work is code and GitHub Projects is the right home, a few setup choices make a large difference to whether the board stays trustworthy.
Keep the Status field short
A board with nine columns becomes a board nobody reads. Four or five statuses, such as Todo, In progress, In review and Done, map cleanly to the life of an issue and its pull request. Put finer detail into other fields rather than more columns.
Turn on the built-in workflows first
Before writing any GitHub Actions, enable the default workflows that set a status when an item is added, when an issue is closed, and when a pull request is merged. These cover the most common moves and cost nothing to maintain. Add auto-archiving so that Done does not grow into a column of hundreds of cards.
Use iteration fields instead of milestone juggling
An iteration field gives every item a sprint, and the board and roadmap can both group by it. Planning the next cycle then becomes a filter on the table view rather than a round of editing milestones across repositories.
Build one view per question
A view should answer a single question. "What is in review right now?" is a board filtered to that status. "What is late?" is a table sorted by target date. "What ships this quarter?" is a roadmap grouped by iteration. Naming views after the question they answer helps new team members find their way.
Check insights before the retrospective
Projects include charts built from project data, with current state and historical charts. A chart of items completed per iteration is often enough to ground a retrospective in numbers rather than impressions.
Use draft issues for triage, then convert
Draft issues are a good inbox for rough ideas raised in planning. Converting them into real issues only when they are ready keeps repositories free of half-formed tickets.
Three ways mixed teams set this up
Teams that have both developers and non-developers usually land on one of three arrangements.
Everything in GitHub Projects
This works when non-code work is a small fraction and the non-developers are comfortable with GitHub. Create a repository for operations tasks, add a Type field to separate kinds of work, and build a view per role. The cost is the ongoing effort of fitting non-code tasks into an issue shape.
Split by audience, link at the edges
Developers keep issues and pull requests in GitHub Projects. Everyone else uses a general project management tool with a kanban board, a Gantt chart and a calendar. When a business task needs engineering work, it links to the GitHub issue rather than copying its details. Each group works in the tool that fits, and a weekly review looks at both.
The risk is duplication. The rule that keeps it under control is simple: one task, one home. A task is either an issue or a card, never both.
Everything in a general tool
Some small teams, especially agencies and studios where code is only part of the delivery, move all planning into a general tool and use GitHub only for code and pull request review. They give up automatic status updates from merges, and in exchange everyone plans in one place. The feature overview shows what a general tool of this kind typically includes, from Gantt to calendar views.
Questions to settle before choosing
A short checklist helps avoid a migration that has to be reversed.
- What share of tasks produce code? If most do, keep planning next to the code.
- Who needs to edit, not just view? Editors need accounts. Viewers can often get by with a shared link or a weekly summary.
- Do you need dated plans with task chains? If a launch depends on a sequence across teams, check that the tool can show and move that sequence.
- Where does discussion happen? If decisions keep landing in chat, a tool with chat next to tasks keeps them attached to the work.
- How will work move between tools? Decide in advance whether links, an integration or a manual review connects them.
If AI assistants are part of how your team plans, it is also worth checking whether a tool can be driven from ChatGPT or Claude, as described on the AI integration page.
What to change first
List last month's completed tasks and mark each one as code or not code. If most were code, stay in GitHub Projects and tune its views; if a large share was not, give that work its own board in a general tool such as Pinateca, and link to issues instead of copying them.
Q1. Does GitHub have a kanban board?
Yes. GitHub Projects includes a board layout that works as a kanban board. Columns come from a single select field, usually Status, and cards are issues, pull requests or draft issues.
Q2. Is GitHub Projects free?
Projects is included on the GitHub Free plan. Paid organization plans add other features and charge per member, so the effective cost depends on how many people need access.
Q3. Can people without a developer background use GitHub Projects?
They can, but each editor needs a GitHub account and access to the organization or repository. Tasks are shaped like issues, which suits code work better than approvals, bookings or content tasks.
Q4. Does GitHub Projects support Gantt charts and dependencies?
The roadmap layout shows items on a timeline based on date or iteration fields. Issues can be marked as blocked by or blocking other issues, and blocked items show an icon on boards, but the roadmap documentation does not describe dependency lines between bars.
Q5. How many items can a GitHub project hold?
GitHub raised the limit from 1,200 to 50,000 items per project in 2025. Each project can also have up to 50 fields, including built-in fields.
