We Tried Using GitHub for Project Management. Here's Where It Broke.
The pitch was compelling. Our code was on GitHub. Our issues were on GitHub. Our pull requests, CI pipelines, and code reviews were all on GitHub. Why were we paying for a separate project management tool when GitHub Projects existed? Why maintain two systems when we could consolidate onto one?
Priya made the case in March. We were paying $1,400 a month for Asana, and the overlap with GitHub Issues was obvious. Half our Asana tasks were just mirrors of GitHub issues with slightly different descriptions. Engineers would update the issue on GitHub but forget to update the card on Asana. Product would update Asana but not check the issue. Same handoff problem, different tools.
So we tried it. We migrated our entire product workflow to GitHub Projects V2. Three months later, we kept GitHub Projects for engineering sprint tracking and went back to a separate tool for everything else.
Here's what happened.
What GitHub Projects Gets Right
The board view is clean. Drag cards between columns, filter by label or assignee, group by custom fields. For a sprint board -- To Do, In Progress, In Review, Done -- it works well. Kenji set up our engineering sprint board in about 20 minutes and the team started using it the same day. No training required because everyone already knew the GitHub interface.
Custom fields were the V2 feature that made the experiment seem viable. You can add fields for priority, sprint number, estimated effort, team -- whatever you need. Views let you slice the same data different ways. Kenji had a board view grouped by assignee. Rafael had a table view sorted by priority. Both looked at the same underlying data.
The built-in connection to issues and PRs is the part no external tool can match. When a PR references an issue, the project board updates. When a PR merges, the linked issue can auto-close. The relationship between "the work" and "the code" is native, not stitched together through a third-party connector that breaks every few months.
Automation within Projects also improved. You can set rules like "when an issue is added to the project, set Status to To Do" or "when a PR is merged, set Status to Done." These are simple triggers, but they handle the most common state transitions without any external tooling.
Where It Broke
The first wall we hit was cross-project visibility. Priya managed three workstreams: platform, growth, and infrastructure. On Asana, she had a portfolio view that showed all three workstreams on one screen -- total items, completion rate, items at risk, upcoming deadlines. On GitHub, each workstream was a separate project. There's no portfolio-level view. She had to open three browser tabs, scan each board, and mentally aggregate the status.
"I feel like I'm managing projects through a keyhole," Priya said after the second week. "I can see one project at a time but never the full picture."
The second wall was reporting. Priya needed to answer: how many items did we complete this sprint? What's our velocity trend over the past six sprints? Which items have been in progress for more than two weeks? Asana had dashboards for all of this. GitHub Projects has no built-in analytics. No velocity charts. No burndown. No cycle time tracking. The data exists in the project's history, but there's no surface for viewing it.
Kenji tried exporting the project data through the GraphQL API and building charts in Google Sheets. It worked, technically. But maintaining the export script, running it weekly, formatting the charts -- that was two hours of work every Monday morning that Asana had handled automatically.
The third wall was non-engineering work. Product specs, design reviews, marketing launch tasks, customer feedback tracking -- this work doesn't map to GitHub issues. An issue is a unit of work in a code repository. A product spec isn't. A design review checklist isn't. A marketing launch plan with 15 subtasks across three teams isn't. We tried creating issues for all of these and it felt wrong, like using a screwdriver as a hammer. The issues cluttered the repo, confused the search results, and mixed product planning with engineering execution in ways that made both harder to find.
Diana started a design review issue that had 47 comments and no code changes. It lived in the frontend repo because that's where design issues "belonged," but it had nothing to do with the frontend codebase. When engineers searched issues for frontend bugs, this 47-comment design discussion showed up in every query. Nobody was happy about it.
The Automation Ceiling
GitHub Projects automations are limited to status field changes triggered by issue or PR events. You can't build automation that reads across projects. You can't trigger actions based on custom field values. You can't create a rule like "if Priority is P0 and Status hasn't changed in 48 hours, send a Slack notification." Asana handles all of these.
We tried filling the gap with GitHub Actions workflows. Kenji wrote a workflow that ran nightly, checked for stale items (no updates in five days), and posted a summary to Slack. The workflow worked, but it was 200 lines of YAML and JavaScript that queried the Projects GraphQL API, which is a separate API from the REST API for issues, with its own authentication and rate limits. The maintenance burden was real.
The deeper problem is that GitHub Projects automations operate on individual items. There's no concept of cross-project rules, portfolio-level triggers, or automations that consider context beyond "this issue changed state." For a simple sprint board, that's fine. For multi-workstream project management, it's a ceiling you hit quickly.
What We Kept
Engineering sprint tracking stayed on GitHub Projects. For a single team tracking issues through a sprint cycle, it's good enough, and the native connection to PRs and CI makes it better than any external tool for that specific use case.
Kenji runs two-week sprints with 15 to 20 issues per sprint. The board shows what's in progress, what's in review, and what's done. When a PR merges, the issue moves to Done automatically. He doesn't need velocity charts because his team is small enough to eyeball the progress. He doesn't need cross-project visibility because he only manages one project.
For his use case, GitHub Projects is the right tool. The problem is that Priya's use case is different from Kenji's, and GitHub Projects only covers Kenji's.
Filling the Gaps with Agents
We went back to a lightweight external tool for product and cross-team work. But we kept GitHub Projects for engineering and used agents to bridge the reporting and visibility gaps.
The first agent we set up was a PR template generator that reads the sprint board and auto-generates PR descriptions with links to the relevant project items. Before this, engineers would reference issue numbers in their PRs but rarely linked to the project board context. The generated descriptions include which sprint the work belongs to, what the priority is, and whether there are related items in other sprints that might be affected.
For the reporting gap, we set up an agent that reads the GitHub Projects data weekly and generates the sprint metrics Priya needs: items completed, items carried over, average time in each status, and items flagged as stale. It's the same data Kenji was manually exporting to Google Sheets, but generated automatically and posted to Slack every Monday morning.
The cross-project visibility gap is harder. We run an agent that pulls items from all three engineering projects (platform, growth, infrastructure) and generates a combined status view. It's not as interactive as Asana's portfolio view -- you can't click and drill down -- but it gives Priya the "full picture" she was missing. She reads it in 90 seconds and knows which workstreams need attention.
Honest Assessment
GitHub Projects is a good sprint board. It's not a project management platform. The distinction matters because "project management" implies reporting, cross-project views, non-code work tracking, and workflow automation that GitHub Projects doesn't provide.
If your team is small (under 15 engineers), works on a single product, and needs a sprint board with native code integration, GitHub Projects will save you a tool subscription and reduce context switching. Use it.
If your team is larger, manages multiple workstreams, includes non-engineering functions like product and design, or needs process metrics and reporting, GitHub Projects will frustrate you. You'll either go back to a dedicated tool or spend a lot of time building workarounds.
We ended up in the middle. Engineering sprints on GitHub Projects because the code integration is worth it. Product and cross-team planning on a dedicated tool because GitHub Projects can't do it. And agents bridging the gap between them -- generating reports from project data, surfacing cross-project risks, and keeping the two systems from drifting apart.
It's not the clean "one tool for everything" story Priya hoped for. But it's the setup that actually works.
Try These Agents
- GitHub PR Template Generator -- Auto-generate PR descriptions with sprint context, priority, and related item links
- GitHub Multi-Repo Audit Agent -- Cross-repo health checks that surface what GitHub Projects' limited reporting can't
- GitHub Config File Updater -- Update configuration across repos when project standards change