GitHub Projects are surprisingly not just a glorified Kanban board, but a powerful, integrated system for planning and tracking work across your entire organization, from individual tasks to long-term roadmaps.
Let’s see it in action. Imagine a team working on a new feature, "User Profile Redesign."
First, we create a new Project. We’ll choose the "Board" template for now, as it’s the most common starting point.
gh project create "User Profile Redesign" --template board
This gives us columns like "To do," "In progress," and "Done." We can add more, like "Needs review" or "Blocked."
Now, let’s add some issues to this project. We can do this directly from an issue page:
[Screenshot of an issue page with "Add to project" button]
Or we can add them in bulk from the project board itself:
[Screenshot of the project board with an "Add issues" button]
Each issue can be assigned to a user, a milestone, and given labels. But the real power comes from the custom fields. We can add fields like "Priority" (Low, Medium, High), "Estimate" (in story points), and "Due Date."
[Screenshot of a project board showing custom fields for issues]
Let’s say we have a "Product Backlog" issue with a "High" priority and an estimated 3 story points.
[Screenshot of an issue in the "To do" column with custom fields filled]
When a developer starts working on it, they move it to "In progress." This automatically updates the issue’s status in the project.
Now, let’s switch to the "Roadmap" view. This is where things get interesting for longer-term planning. We can group issues by "Milestone" or "Date Range."
[Screenshot of the Roadmap view showing issues plotted over time]
Here, we can see our "User Profile Redesign" feature, which we’ve assigned to the "Q3 Launch" milestone, stretching across several weeks. We can also see dependencies between issues. If "Frontend Implementation" depends on "API Design," the roadmap visually shows this link.
[Screenshot of the Roadmap view highlighting a dependency between two issues]
To manage sprints, we can switch to the "Sprints" view. This works similarly to the board, but with added sprint-specific features. We can define sprint durations, assign issues to a sprint, and track progress within that sprint.
[Screenshot of the Sprints view showing a backlog and active sprints]
We can drag issues from the backlog into an active sprint. The project automatically calculates the capacity needed and warns if we’re over-committing.
[Screenshot of the Sprints view showing an issue being dragged into a sprint, with capacity warnings]
The "Analytics" tab provides insights into our team’s velocity, cycle time, and throughput. This data is crucial for improving our planning and execution.
[Screenshot of the Analytics tab showing charts for velocity and cycle time]
One of the most powerful, yet often overlooked, aspects of GitHub Projects is its ability to pull data from multiple repositories. This means you can have a single project board that tracks work across different microservices or even different teams’ repositories, giving you a unified view of your entire product development lifecycle. You’re not limited to just the issues within the repository where the project is created.
The next logical step is to integrate this project data with your CI/CD pipeline, automatically updating issue statuses based on deployment events.