The best thing about GitHub Projects is that it is already there. If your work lives in GitHub, your planning can live one tab over, in the same place as the issues and pull requests, under the same logins, for no extra money. That is a real advantage, and any honest comparison has to start by admitting it. A dev-only team that wants a lightweight board next to its code could do a lot worse than the tool that ships free with the account they already have.
GitHub has also quietly made Projects more capable than people give it credit for. The same is true of Azure DevOps Boards, the other tracker teams inherit rather than choose. There is a native Iteration field, so you can define time-boxed cycles that behave like sprints. Since July 2026 there are native issue fields, so an Effort estimate is built in rather than invented. There are Insights charts that can total a field across iterations or plot it over time. For planning at a certain altitude, this is genuinely enough.
Then a scrum team asks the tool one specific question, and the answer is a shrug.
The chart that is there, and the ones that are not
The question is: how is this sprint tracking, and how fast does our team actually go? In scrum terms, show me a burndown or a burn-up, and show me velocity.
Half of that has an answer, and it is better than Projects usually gets credit for. Insights has a default chart called Burn up, free on every plan, which plots your items over time as completed, open, closed and not planned. Historical charts are real too: put time on one axis, the sum of a number field such as Effort on the other, filter to one iteration, and you have a points burn-up for that sprint.
The other half is still missing, and it is the half that costs a team time. There is no burndown. There is no velocity trend across iterations, so nothing tells you that the team has landed roughly eighteen points a sprint for six sprints. And the burn-up has no separate scope line, which is the whole reason a burn-up beats a burndown, so scope arriving mid-sprint does not announce itself the way it should. Each chart is also something you configure and filter per iteration rather than something the tool keeps for every sprint by itself. The community thread asking for native burndown and velocity has been open since November 2022, with no answer from GitHub since May 2023.
To be fair about the direction of travel, 2026 has been a good year for Projects. Sub-issues became a real hierarchy in March, eight levels deep with grouping and filtering intact, which is the epic-to-story breakdown teams used to bolt on. Issue fields went generally available in July with Priority, Effort, Start date and Target date built in, so the estimate is no longer a custom field you invent. None of it was reporting, and that is the pattern: the planning half keeps improving, the measurement half stays where it was.
There is a second limit that bites the moment you want people outside the codebase to see the plan. A public project is visible to anyone, fine. But items from a private repository are only visible to people who can access that repository, and on paid GitHub plans every private-repo collaborator is a billable seat. So there is no clean, free, read-only view for a product manager, a client, or an executive who just wants to watch. To see the board, they need repo access, which means a seat.
Staying next to the code without giving up the reporting
The reason developers reach for GitHub Projects is that they do not want to leave their workflow to plan. That instinct is right. The mistake is assuming the only way to honor it is to accept no real scrum reporting.
Scrumpy is built to sit alongside that same workflow while giving you the numbers GitHub Projects will not. Story points, velocity and a sprint burn-up chart are native and update as you complete work, per sprint, with nothing to configure each time. Each story links straight to its branch, and it works with both GitHub and GitLab, not just one host. There is a small REST API to create stories from your own scripts, and a command to start a story from the CLI without opening a browser, so the tool meets you where you already are. And every stakeholder who just wants to watch is free, no repo seat required.
If your team never needs velocity or a burndown and nobody outside the repo needs to see the board, GitHub Projects is free and right there, and I would not talk you out of it. But the day someone asks how fast the team goes, and the honest answer is a spreadsheet you rebuild every Monday, that is the day a purpose-built board earns its keep. You can keep your GitHub flow and add the reporting instead of exporting it by hand.
Frequently asked questions
Can GitHub Projects do scrum?
Partly. GitHub Projects has a native Iteration field for sprint-like cycles, native issue fields including Effort, and a default Burn up chart in Insights. What it lacks is the rest of scrum reporting: there is no burndown, no velocity trend across iterations, and no scope line, so each sprint's chart is something you configure and filter yourself.
Does GitHub Projects have burndown or velocity charts?
Half of one. Insights ships a default Burn up chart that plots completed and remaining items over time, and you can build a historical chart of a number field such as Effort. There is no burndown chart and no velocity trend across iterations, so a sprint-by-sprint pace still comes from a spreadsheet or another tool.
Can stakeholders view a private GitHub project for free?
Not really. A public project is visible to anyone, but items from private repositories are only visible to people with access to those repositories, and on paid GitHub plans each private-repo collaborator is a billable seat. There is no free read-only viewer for private work.
Is GitHub Projects enough for a development team?
For a dev-only team that wants lightweight planning next to the code and does not need velocity or burndown, GitHub Projects is a strong, free option. Teams that run formal sprints with estimation and reporting, or that need free stakeholder access, usually add a dedicated scrum tool.
