GitHub Projects is great, until your team needs a real sprint

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. There is a native Iteration field, so you can define time-boxed cycles that behave like sprints. You can add an estimate as a custom number field. There are Insights charts that can total a field across iterations. 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 has not arrived since 2022

The question is: how is this sprint tracking, and how fast does our team actually go? In scrum terms, show me a burndown or burn-up, and show me velocity.

GitHub Projects cannot. There is no native burndown, no burn-up, and no velocity trend. The Insights charts give you a current snapshot, a sum of points grouped by iteration, but not the moving picture of a sprint burning down against its scope, and not a velocity you can plan the next sprint around. This is not a niche request either. The community thread asking for native burndown and velocity has been open since November 2022, upvoted for years, and it still has not shipped. Teams that need those numbers end up pulling data out through the GraphQL API into a spreadsheet every Monday, which is a lot of ceremony to rebuild a chart the tool could have drawn.

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 burn-up chart are native and update as you complete work, so you are not exporting anything to a spreadsheet to see whether a sprint is on track. 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 whether the sprint is on track and you find yourself reaching for the GraphQL API to answer, 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.