GitHub Projects for planning for Git & GitHub developers

GitHub Projects for planning for Git & GitHub developers

Most teams we work with across e-commerce, SaaS, and trading platforms still manage their sprint planning in separate tools. GitHub Projects eliminates that friction by bringing lightweight project management directly into the platform where your code lives. If you're tracking issues and pull requests in GitHub but planning work elsewhere, you're creating a context-switching tax that compounds throughout the sprint.

Over the last decade, we've watched project management tools evolve from heavyweight solutions to lightweight overlays. GitHub Projects represents the natural endpoint of that evolution: a planning layer that understands Git commits, pull requests, and issues natively, without forcing you to maintain duplicate state. This guide walks you through using GitHub Projects effectively for sprint planning, backlog grooming, and tracking delivery progress.

Board and table views

GitHub Projects offers two complementary views of the same data: a Kanban-style board and a spreadsheet-like table. The board view is what most teams reach for first, and for good reason—it mirrors the mental model of moving work through states like "Todo," "In Progress," and "Done." The table view becomes invaluable once your backlog grows beyond a dozen items, letting you sort, filter, and bulk-edit at scale.

Here's the workflow we recommend: use the board view during standups and when you want a quick visual of what's in flight. Use the table view for grooming sessions, sprint planning, and when you need to understand dependencies across multiple work items.

Start by creating a new project in your repository settings. GitHub gives you templates for "Table" and "Board"—pick Board for your first pass. When you add your first issue or PR to the board, it automatically creates the default status columns. You can customize these to match your team's workflow: "Backlog," "Ready," "In Progress," "In Review," "Done" is a common pattern we use in NestJS and Next.js projects.

The board view respects drag-and-drop, so updating status is as simple as moving a card left or right. This tactile feedback helps reinforce progress, especially in async teams where you don't have a physical board.

To switch to table view, click the layout toggle in the top-right. The table lets you group by any field—try grouping by Status first, then by Priority. You can also sort by due date, assignee, or any custom field you've created. For teams with dozens of issues in flight, the table view becomes your source of truth for capacity planning.

Both views stay synchronized. Moving a card on the board updates the status in the table. Editing a field in the table updates the board. This consistency is crucial—it means there's only one state to trust.

Custom fields for priority and size

GitHub Projects' custom fields are what separate it from a basic Kanban board. You can add Priority and Size fields to every issue, then use those to drive automation and reporting. Priority helps you focus the team on what matters most. Size lets you spot if the sprint is overcommitted.

To add a custom field, open your project settings and click "Custom fields." Create a "Priority" field with options like Critical, High, Medium, Low. Create a "Size" field with options like XS, S, M, L, XL—these map to story points or t-shirt sizing depending on your team's preference.

Now every issue can be tagged with both. The real power emerges when you filter. In your board view, add a filter: Status is "In Progress" AND Priority is Critical. This shows your team only the highest-impact work in flight. During sprint planning, sort by Size and Priority to ensure you're filling the sprint with a balanced mix of small high-priority fixes and medium-sized features.

We've found that a simple scoring system works well: count all XS and S items as 1 point each, M items as 2, L as 3, XL as 5. This lets you estimate sprints without formal estimation sessions—just add up the sizes of items you pull in.

Here's how we structure priorities in a typical e-commerce sprint: Critical items are production issues or items blocking another team. High items are user-facing fixes that impact revenue or satisfaction. Medium items are technical debt or internal improvements. Low items are nice-to-haves for future sprints. Review these definitions with your team—they should match your business reality.

Automations on status changes

Automations in GitHub Projects eliminate manual busywork. The most common automation we use is: when an issue moves to "In Progress," assign it to the person who moved it. When it moves to "Done," add a label that gets automatically applied. These micro-automations compound to save hours over a quarter.

To set up automation, open your project settings and find the "Workflows" section. GitHub provides pre-built workflows for common cases. Enable "Auto-add to project" so every issue and PR in the repository automatically appears in your project (you can filter later). Enable "Auto-update when issues and pull requests change" to keep status synchronized.

For custom automations, use GitHub's Actions integration. Here's a practical example: when a PR linked to an issue is merged, automatically move the issue to "Done." This reduces the cognitive load—you don't need to remember to close issues manually.

Create a workflow file in your repository at .github/workflows/project-automation.yml:

name: Update project on PR merge
on:
  pull_request:
    types: [closed]
    
jobs:
  update-project:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            const pr = context.payload.pull_request;
            if (!pr.merged) return;
            
            const issues = await github.rest.issues.listForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              creator: pr.user.login
            });
            
            // Find linked issues and update their status in the project
            // Implementation depends on your project structure

A simpler approach: use GitHub's native automation. In your project settings, create a workflow: "When items are added to the project, set status to 'Backlog'." Another workflow: "When a pull request is opened and is linked to an issue, move the issue to 'In Progress'." These built-in automations don't require code and work reliably.

We've also had success with a "staleness check"—any issue that's been in "In Progress" for more than 5 days gets flagged with a comment asking for a status update. This catches blockers and stuck work before standup.

Link issues and pull requests

Linking issues and PRs is the glue that makes GitHub Projects powerful. When you link a PR to an issue, GitHub's project automation can move the issue through statuses. When you reference an issue in a PR description with "Closes #123," merging the PR automatically closes the issue.

To link a PR to an issue, open the PR and look for "Linked issues" in the sidebar. Click "Link an issue" and search by number or title. The link is now bidirectional—the issue shows "Linked pull requests" with a reference back to the PR.

This linking becomes invaluable in teams with code review processes. Picture this scenario: a developer opens a PR to fix a production bug. They link it to issue #487. As soon as the PR is opened, your project automation moves #487 to "In Review." Reviewers can see the issue and PR side-by-side, understanding the full context. When the PR merges, the issue closes and moves to "Done" automatically.

For large features that span multiple PRs, you can use issue templates that include a "Related PRs" section. Each PR links back to the epic or feature issue. This gives you a single source of truth for the feature's progress: you can see all its PRs, comments, and reviews in one place.

In trading and real-time applications, we've used linking to correlate code changes with business events. When a data consistency bug is filed, we link it to the PR that introduced the regression. The project board then shows the full chain: original issue → regression PR → fix PR → resolution. This historical trail is invaluable during post-mortems.

Common mistakes

The most frequent mistake we see is creating too many custom fields. Teams start with Priority and Size, then add Effort, Complexity, Risk, Owner, Quarter, and ten more fields. After three months, half the fields are stale and updating them becomes a chore. Start with two fields: Priority and Size. Add more only when you have a clear need.

Another trap: letting the project board diverge from the source of truth. If an issue is closed in GitHub but still marked "In Progress" on the board, you now have conflicting information. Prevent this by strictly using automations—make status changes in the project drive issue state, not the other way around.

Over-automating is also common. Not every action needs an automation. If you're creating automations for things that happen twice a quarter, you're adding complexity that doesn't pay dividends. Focus automations on your team's most repetitive bottlenecks.

Finally, don't treat GitHub Projects as a replacement for documentation. The board should reflect what's being built, but it shouldn't contain the requirements themselves. Keep design docs, architecture decisions, and acceptance criteria in your repository's wiki or README. The project board is a status tracker, not a specification system.

Key takeaways

• Board and table views let you visualize the same data two ways—use boards for standups, tables for sprint planning and capacity analysis.
• Custom fields for Priority and Size drive both planning and automation decisions; start simple with just these two.
• Status-change automations eliminate manual updates; focus on the two or three automations that save your team the most time.
• Linking issues to PRs creates a complete audit trail; lean on this during code review and post-deployment verification.
• Keep your project board in sync with your repository's source of truth by using automations exclusively for status updates.
• Resist the urge to model every business concept as a field—GitHub Projects is a lightweight tool that works best when kept simple.