GitHub Projects Review: Can Built-in Project Management Replace Jira?

Every developer has the moment. You finish a code review, merge a PR, and open Jira to update the ticket status — then realize the ticket still references a branch that was deleted two weeks ago, the “fix version” field wasn’t updated, and the sprint burndown chart now shows a spike that will confuse your PM in tomorrow’s standup. The data lives in one place and the project tracking lives in another, and every engineer on your team pays the context-switching tax dozens of times a day.

GitHub Projects makes a different bet: what if the project board lives exactly where the code, issues, and pull requests already are? We moved three engineering projects — a combined 247 open issues and 34 active PRs — from Jira Cloud to GitHub Projects in March 2026 and ran four two-week cycles to understand what the built-in approach actually delivers. Here’s what we found.

Table, Board, and Roadmap: Views That Actually Ship Work

GitHub Projects launched as a rebranded version of the old project boards in 2022 and spent three years catching up. The current product (as of mid-2026) supports three primary views — table, board, and roadmap — and each serves a different layer of the team.

The table view is where we spend most of our time. It surfaces issues and PRs as rows with configurable columns for status, priority, assignee, sprint, and any custom field you define. The inline editing is fast — click a cell, change a value, and the update commits immediately without a full page reload. We built a table view that shows every open bug across all three projects sorted by priority, and it became the first tab our engineering lead opens every morning.

The board view is the Kanban interface most teams reach for during sprint planning. Drag an issue from “Backlog” to “In Progress” and the status field updates. The board respects group-by rules, so we split one board by assignee for individual standup views and another by sprint for planning sessions. The interaction is smooth and performs well even with 150+ cards visible — something the old GitHub project boards struggled with badly.

The roadmap view is the newest addition and the one that reveals GitHub’s ambition. It renders issues and PRs on a Gantt-style timeline based on start dates and end dates you set via custom fields. For our team of seven engineers, this replaced a spreadsheet we used to maintain for quarterly planning. You can zoom from quarters down to weeks, drag items to reschedule them, and group by milestone or assignee. It is not a Jira Advanced Roadmaps replacement — there are no task-level dependencies, resource-leveling heatmaps, or cross-project rollups — but for a single-team view of what ships when, it does the job without requiring anyone to learn a new tool.

The common thread across all three views is that they work on the same underlying data. Apply a filter in the table view — “bugs with priority high, not updated in seven days” — and switch to the board or roadmap and the filter persists. This sounds obvious, but in Jira, saved filters, boards, and roadmaps are separate objects with separate configurations. The unified data model means you configure once and navigate however your brain works that morning.

Custom Fields, Workflows, and Auto-Linking: The Plumbing That Matters

Custom fields in GitHub Projects are simpler than what Jira or Linear offer, but they cover the 80 percent of cases that matter: single-select, text, number, date, and iteration (sprint). We set up an iteration field named “Sprint” with two-week cycles, a single-select “Effort” field with T-shirt sizes for rough estimation, and a date field for “Target Ship Date” that feeds into the roadmap view.

The workflow system is the piece that trips people who expect Jira-level configurability. GitHub Projects supports a project-level status field where you define columns. You can tell it which column items land in when they are added and whether items in that column count as closed. But you cannot define transition rules (“an issue cannot move to Done unless it has a linked PR”), approval gates, or per-issue-type workflows. For our team, this was enough — we use four statuses (Backlog, Ready, In Progress, Done) and the simplicity kept us from overengineering. For a compliance-heavy team with five approval stages and mandatory QA sign-off, it would be insufficient.

The auto-linking feature is where GitHub Projects earns its biggest advantage. When you write “Closes #247” in a PR description, the issue moves to Done automatically when the PR merges. When you reference an issue from a commit message, the commit appears in the issue timeline. When you link a PR to a project, it inherits the project’s status field. None of this requires configuration — it works because issues, PRs, commits, and projects all live in the same namespace. We stopped writing “Updated Jira ticket PROJ-482” in PR descriptions entirely. The tracking happened passively as we wrote code.

The GraphQL API: Programmatic Control Over Everything

GitHub Projects is managed through GitHub’s GraphQL API (v4), and the surface area is complete. You can query projects, fields, items, and field values with a single request, and mutations let you create, update, and delete project items programmatically. This matters for teams that want to build custom dashboards, sync external data, or automate project management outside of GitHub Actions.

We built a lightweight internal dashboard that queries project data — open bugs by severity over the last four sprints, throughput per engineer, and average time from issue creation to merge — and displays it in a Retool panel that our product manager checks on Monday mornings. The GraphQL queries are verbose (a single request for “all high-priority items with their current status and sprint” runs about 40 lines), but they are predictable and the API documentation is thorough.

The practical limitation is rate limiting. GitHub’s GraphQL API enforces point-based rate limits, and a query that pulls 200 project items with all field values can consume 50-80 points. For lightweight dashboards this is fine, but if you are building a real-time sync with an external reporting tool that polls every two minutes, you will hit the ceiling. Teams running large-scale automation around GitHub Projects should use webhooks — which fire on issue and project events without consuming API points — and fall back to GraphQL only for deeper queries.

Where GitHub Projects Falls Short

The honest assessment after four cycles is that GitHub Projects does three things well enough to depend on them and three things poorly enough that you will need workarounds.

Reporting is the biggest gap. GitHub Projects has no built-in velocity tracking, no cumulative flow diagram, no cycle time analytics, and no burndown charts. You can see what is in each sprint and what got completed, but you cannot generate a chart that shows sprint-over-sprint throughput trends without pulling data through the API and building your own visualization. Our engineering lead spent two afternoons exporting issue data to a CSV and building a velocity tracker in Google Sheets. That is fine for a seven-person team doing it once. It does not scale to a 40-person engineering org where three PMs and a VP expect reporting on a predictable cadence.

Portfolio management does not exist. GitHub Projects is scoped to a single project — there is no cross-project rollup view that shows the status of five concurrent projects against their respective milestones. Atlassian sells this as Advanced Roadmaps; Linear handles it through workspace-level initiatives. GitHub has nothing analogous. If your engineering org runs multiple teams with interleaved dependencies, you will need a separate layer (a spreadsheet, a Notion page, a third-party tool) to stitch the picture together.

Non-developer usability is the third real problem. GitHub’s UI is built for developers. The terminology (issues, pull requests, repositories, branches), the navigation model (repository-first), and the filtering syntax (is:issue label:bug project:"Backend/7") assume the user lives in GitHub eight hours a day. Our product manager adapted because she spends enough time in GitHub for PR reviews that the context was familiar, but our designer gave up after two sprints and asked us to mirror the prioritized backlog in a Notion page she could sort and filter without learning GitHub’s query syntax. In Jira, a stakeholder creates an account, joins a project, and drags cards on a board. In GitHub Projects, they need to understand repositories, issues, and labels before the board makes sense.

Which Teams Should Keep Project Management in GitHub

GitHub Projects is the right tool for developer teams of 2 to 15 people who already manage their work through GitHub issues and pull requests. The auto-linking between code and tracking eliminates the single largest source of project management friction — the constant, manual synchronization between “what the board says” and “what the code says.” When the board updates itself because someone pushed a branch or merged a PR, nobody has to be the status-update person, and nobody has to audit whether the board is stale.

The zero-context-switching advantage is real and measurable. Our developers open roughly 40 issues and 25 PRs per week across the team. Every one of those is automatically linked to its project, status, and sprint without anyone visiting a separate tool. Compare this to the Jira workflow we ran before: open a PR, copy the branch name, switch to Jira, paste it into a comment, update the status, and verify the ticket links are correct. That is 45 seconds per PR, multiplied by 25 PRs per week, multiplied by 52 weeks — roughly 16 hours of developer time per year spent on manual synchronization. GitHub Projects eliminates that entire category of work.

The teams where GitHub Projects does not work are equally clear. If your engineering org has more than 20 developers with multiple interdependent teams, the lack of portfolio views and cross-project rollups will create more coordination overhead than the tool eliminates. If non-engineering stakeholders need direct access to the project board — for status checks, reporting, or task creation — the developer-oriented UI will generate a steady stream of Slack messages asking “what does this status mean” and “why can’t I filter by department.” And if your process requires compliance-mandated workflow stages with approval gates, you need a tool with a workflow engine, not a Kanban board with auto-linking.

The middle ground — a 5-to-12-person engineering team that finds Jira heavy and Linear expensive — is where GitHub Projects makes its strongest case. You are already paying for GitHub. The features that matter (issue tracking, sprint planning, PR auto-linking, and basic automation) work well enough to run a real engineering process on. The gaps (reporting, portability, non-dev UX) require workarounds, but the workarounds are one-time costs that pay back every cycle in eliminated context switches.