GitHub Projects can show the same work as a table, board, or roadmap. That is the useful part. It means a team can change the question it is asking without copying issues into three separate tracking systems.
The mistake is treating each layout as a different backlog. A table, board, and roadmap should be different windows onto the same set of issues and pull requests. If each view becomes its own source of truth, the project gets harder to trust.
Use a table for backlog triage
A table is the best default when you need to scan many items and make precise edits. It is useful for an unplanned backlog, weekly prioritization, bug triage, and release preparation.
- Filter by status, label, assignee, repository, or milestone.
- Sort by priority, target date, or another field.
- Show the fields needed for the decision and hide the rest.
- Edit several items without moving cards between columns.
A table answers questions such as: Which unstarted items are high priority? Which issues have no owner? Which pull requests are waiting for review? It favors density and comparison over visual flow.
Use a board to manage flow
A board is useful when work moves through a small number of states, such as Todo, In progress, In review, and Done. It makes work in progress visible and gives the team a shared view during a standup or planning session.
- Keep the number of columns small enough to scan quickly.
- Use a status field that describes the team’s workflow, not every possible activity.
- Add a work-in-progress limit when too many active items create bottlenecks.
- Group by a useful dimension, such as assignee or priority, only when it supports a real discussion.
A board answers: What is moving? What is stuck? Where is the team spending its attention? It is less useful when the project has hundreds of items or when dates and dependencies matter more than flow.
Use a roadmap for dates and sequencing
A roadmap is designed for work that needs a time horizon. Use it for planned releases, product milestones, major initiatives, or cross-team commitments. It helps people see when work is expected to happen and how items relate to a target date.
- Give larger work a target date or a clear time range.
- Use a small number of milestones or initiatives so the timeline stays readable.
- Treat dates as planning signals, not promises that cannot change.
- Review items that have no date and decide whether they belong on the roadmap at all.
A roadmap answers: What are we aiming to deliver next? Which work is approaching? What has slipped? It is not a replacement for a detailed engineering backlog.
Build the views around questions
Start with the decisions your team makes each week. Then create one saved view for each recurring question. A practical starting set looks like this:
- Backlog table: items that are open, unstarted, or missing an owner.
- Team board: active work grouped by status.
- Release roadmap: items with target dates for the next release or quarter.
- Review queue: pull requests that need a reviewer or a decision.
The exact names do not matter. The filters and fields do. A view should make one question easier to answer than the default project view.
Keep project data connected to the work
Projects can include issues, pull requests, and draft issues. Changes to linked GitHub data are reflected in the project, so teams should update the issue or pull request when that is where the information belongs. Use project fields for planning metadata that does not belong in the issue itself, such as priority, estimate, or target date.
GitHub describes Projects as a collection of issues and pull requests that can be viewed in multiple layouts. Read the GitHub’s overview of Projects
For practical guidance on filters, fields, and saved views, see GitHub’s project best practices
Avoid three common setup problems
- Too many statuses: If every handoff gets its own column, the board becomes a process diagram instead of a work view.
- Too many fields: Add fields when they change a decision. Remove fields that nobody maintains.
- Duplicate tracking: Do not copy an issue into a spreadsheet and a second board unless there is a clear reason and an owner for the sync.
A simple setup that works
Create a project at the user or organization level, add the repositories that belong in its scope, and start with the default table. Add a status field, a priority field, and a target date only if the team will use them. Then save a board view for active work and a roadmap view for dated work.
The official setup flow is covered in GitHub’s project creation guide
After a week, ask which view the team actually used. Improve the filters and remove anything that made the project harder to maintain. A small set of trustworthy views is more useful than a perfectly customized project that nobody opens.
The table, board, and roadmap are not competing project management methods. They are different ways to look at the same GitHub work. Choose the layout based on the decision in front of you, and keep the underlying issues and pull requests as the source of truth.