GitHub Projects added iteration fields in 2023, which means you can now run sprints natively in GitHub. But GitHub still does not give you velocity charts, capacity planning, or sprint health metrics. You need external tools for the math.
This guide shows you how to pair sprint velocity tracking with GitHub Projects to run tighter sprints without leaving your development environment.
The Gap in GitHub Projects
GitHub Projects supports custom fields, views, and iterations. You can group Issues into two-week cycles and move them across status columns. What you cannot do is answer these questions:
- What is our average velocity over the last 6 sprints?
- Can we fit this scope into the next sprint based on historical capacity?
- Which types of work consistently blow past estimates?
These questions require data that GitHub does not aggregate for you.
Setting Up Sprint Tracking
Step 1: Add story points to GitHub Projects. Create a custom number field called "Points" in your GitHub Project. Assign point values to each Issue before the sprint starts. Use Fibonacci (1, 2, 3, 5, 8, 13) or t-shirt sizes mapped to numbers.
Step 2: Track completed points per sprint. At the end of each iteration, count the total points for Issues moved to "Done." Record this number in the sprint velocity calculator.
Step 3: Calculate your rolling average. After 3+ sprints, the calculator shows your rolling velocity. Use this number, not your best sprint, when planning the next cycle.
Step 4: Plan against capacity. Before each sprint, add up the points for candidate Issues. If the total exceeds your rolling average, cut scope. Do this before committing to the sprint, not midway through.
GitHub Projects Configuration Tips
Create a "Sprint Review" view in your GitHub Project. Filter by the current iteration and group by status. This gives you a snapshot of where everything stands without leaving GitHub.
Use GitHub's built-in chart feature to visualize Issue counts per iteration. While this does not show point-based velocity, it gives you a rough throughput metric.
For teams that use GitHub Milestones instead of Projects iterations, the same workflow applies. Create a Milestone per sprint, assign Issues, and track completed points at close.
Prioritizing What Enters the Sprint
Not every Issue deserves sprint commitment. Before sprint planning, score your backlog candidates using the RICE framework or the RICE Calculator. High-scoring items enter the sprint first.
This prevents the common failure mode where urgent-but-low-impact tickets crowd out important work. A scored backlog gives your team a defensible ordering.
Common Mistakes with GitHub Sprint Planning
Counting Issues instead of points. Ten one-point Issues and two thirteen-point Issues are not the same workload. Always plan by points, not ticket count.
Skipping the retrospective. GitHub does not prompt you to reflect after each iteration ends. Schedule the retro yourself. Use the retrospective generator to structure the discussion.
Ignoring carry-over. Unfinished Issues from last sprint consume capacity this sprint. Subtract carry-over points from your available velocity before adding new work.
Review roadmap templates if you need to connect sprint-level execution to quarterly product plans.