How to Track Sprint Velocity With GitHub Projects (Without a Spreadsheet)

GitHub Projects is a genuinely good place to manage issues and PRs for a small dev team — it’s already where the code lives, so there’s no separate tool to keep in sync. But it doesn’t natively answer a question every team eventually asks: what’s our velocity, and are we on track for this sprint?

GitHub Projects will show you what’s open, what’s closed, and what’s in progress. It won’t plot points-per-day, project whether you’ll hit a sprint goal, or show a trend over time without you building it yourself.

The default workaround (and why it breaks down)

Most teams’ first solution is a spreadsheet: manually tally story points from closed issues at the end of each sprint, maybe chart it if someone’s motivated. This works for exactly as long as someone remembers to update it consistently — which, for most teams, is a few sprints.

The core problem is that it’s a second system. GitHub Projects has the real state (what’s actually closed); the spreadsheet has to be manually kept in sync with it. Any gap between those two — a forgotten update, a mis-tallied point value — makes the velocity number untrustworthy, and an untrustworthy metric gets ignored.

What “closing the gap” actually requires

To get real velocity tracking out of GitHub Projects without manual reconciliation, you need something that:

1. Reads issue/PR state directly from GitHub — no parallel manual entry
2. Logs points the moment an issue closes — not at a manual end-of-sprint tally
3. Turns that into a trend line, not just a running total — daily velocity, and ideally a projection of whether the sprint goal is reachable at the current pace
4. Requires no new habit from the team — if using the tool means doing anything beyond “close the issue like you already do,” adoption will be inconsistent, and an inconsistently-updated velocity number is worse than none

What this looks like in practice

ScoreZen connects to GitHub Projects and logs points automatically the moment a linked issue closes — no manual entry, no end-of-sprint reconciliation. That feeds a daily velocity chart and a burn-up view showing cumulative progress against an ideal pace line, so “are we on track” is answered by a single glance instead of a spreadsheet audit.

For teams that want the motivational layer too, there’s a real-time leaderboard on top of the same underlying data — same source of truth, just a different view depending on who’s looking.

It’s free for teams up to 5 people, setup takes about two minutes (connect GitHub, done), and there’s no separate system to keep in sync. Try it here.