GitHub Projects - Project Management That Doesn't Suck (Much)

I've been using GitHub Projects for about 8 months after migrating our team from Jira. Here's what surprised me and what you should know before diving in.

The Problem GitHub Projects Actually Solves

Look, if you're already living in GitHub - tracking issues, reviewing PRs, managing releases - then constantly switching to Jira or Trello to update project status is fucking exhausting. You close an issue, then you have to remember to move a card. You merge a PR, then you update another system. GitHub Projects fixes this by just... not making you do that anymore.

When you close an issue, your Kanban board updates automatically. When you create a PR, it shows up in the right column. When you merge code, your roadmap reflects it. This isn't revolutionary - it's just what should have happened years ago.

What's Different Now (As of 2025)

The original GitHub Projects was honestly pretty terrible. Limited to 1,200 items, bare-bones features, felt like an afterthought. But GitHub finally got serious in early 2025 and bumped it up to 50,000 items per project, added sub-issues, and included actual search functionality.

I learned this the hard way when our main project board hit the old limit and just... stopped working. Had to split everything up. The new limits are way more reasonable unless you're doing something truly insane.

The Three Views You'll Actually Use

Table View: This is your spreadsheet for data nerds. I spend most of my time here because you can bulk edit shit, filter by weird criteria, and see everything at once. Great for sprint planning when you need to assign story points to 30 issues without clicking around like an idiot.

Board View: Classic Kanban. We have columns for "Backlog," "In Progress," "Review," "Testing," and "Done." Issues move automatically when their status changes, which still feels like magic after years of manual card shuffling in Trello.

Roadmap View: Timeline view for when your PM asks "when will this ship?" It's decent for high-level planning but gets messy with too many items. The dependency visualization is useful but breaks down if you have complex interdependencies.

Custom Fields That Don't Suck

You get 50 custom fields per project, which sounds like a lot until you start using them. We track:

• Story points (number field) - because apparently we still do that
• Priority (dropdown) - High/Medium/Low because anything more complex is overthinking it
• Sprint (iteration field) - works well with their built-in iteration planning
• Component (text) - frontend, backend, infrastructure, etc.
• Bug source (for tracking where things went wrong)

Pro tip: Don't go crazy with custom fields initially. Start simple and add them when you actually need them, not because you think you might.

Automation That Occasionally Works

The built-in automation is pretty basic but handles the common stuff:

• Auto-move items when PRs get merged
• Archive completed items after 30 days
• Add new issues with specific labels to projects automatically

I spent 3 days setting up complex automation rules that GitHub broke in the next update. Keep it simple. The GraphQL API is powerful if you want to get fancy, but the learning curve is brutal and the docs could be better.

What Actually Breaks

• Mobile experience is trash - you'll be stuck at your desktop for any real project management
• Performance gets sluggish with large datasets (approaching that 50k limit)
• Reporting is basic - if you need fancy charts and burn-down reports, you'll be disappointed
• API rate limits bite you during bulk operations - learned this during our Jira migration
• Automation rules conflict sometimes and create infinite loops that spam your entire team (yes, this happened)

The biggest gotcha: GitHub Projects works great until you need complex permissions or your org has weird security requirements. Then everything becomes 10x harder.

Resources and References

For deeper understanding, check out the GitHub Projects API documentation, the project automation guides, and the GitHub CLI project commands. The GitHub Community discussions are invaluable for troubleshooting weird edge cases, and the GitHub changelog will keep you informed about feature updates that might break your existing workflows.

After migrating 3 different teams from various tools to GitHub Projects over the past year, here's what I learned the hard way about implementation. Spoiler: most "best practices" are bullshit consultant advice.

Start Simple or You'll Hate Everything

Forget the elaborate project structures you see in tutorials. I tried setting up our first project with 15 custom fields, complex automation rules, and multiple views from day one. Result? Nobody used it and we went back to Jira for 2 weeks.

What actually works: Start with basic issue tracking and add one feature at a time. We literally began with:

• Basic Kanban board (To Do, In Progress, Done)
• Priority field (High/Medium/Low - anything more complex is overthinking)
• One automation rule: move to Done when issues close

That's it. Build the habit first, then add complexity when people aren't fighting the tool.

Repository vs Organization Projects: This depends on your team structure, not some grand strategy. Small teams working in 1-2 repos? Repository-level projects work fine. Multiple teams across many repos? Organization-level or you'll have chaos. We learned this by creating 12 separate repository projects that nobody could find.

Automation That Won't Break Everything

GitHub's automation is simple enough that you can't fuck it up too badly, but I've seen teams create notification storms that made Slack unusable.

Safe automation rules to start with:

• Auto-archive closed items after 30 days
• Add new issues with specific labels to your project
• Move items to "In Review" when PRs are opened

Dangerous automation to avoid initially:

• Complex field updates that trigger other field updates
• Multiple rules that modify the same items
• Anything involving external webhooks until you understand the system

I spent a weekend fixing an automation loop that updated status fields every time someone breathed on an issue. Test automation on a throwaway project first.

Migration Reality Check

From Jira: The import tools are basic and will disappoint you. You'll lose:

• Complex custom field mappings
• Historical workflow data
• Advanced query structures
• Most of your automation rules

Plan for manually recreating about 60% of your configuration. We did the migration over 6 weeks, moving one product team at a time. Any faster and people revolt.

From Trello: Actually pretty smooth since both are simple. Main issue is losing Power-Up functionality and having to recreate board automations.

From nothing: Easiest scenario. Set up basic structure and let usage patterns inform your configuration rather than over-engineering upfront.

The Shit That Will Actually Break

Performance degrades badly with large datasets. Don't believe the "50,000 item" marketing. Around 15,000+ active items, the interface gets sluggish and bulk operations become painful.

Mobile is genuinely terrible. If your team needs mobile project management, choose a different tool. The GitHub mobile app shows project data but you can't do real work. I learned this during a week of travel when I couldn't update sprint progress because mobile editing is broken.

API rate limits bite during bulk operations. We hit the 5,000 requests/hour limit during our Jira migration and everything stopped working for 2 hours. Plan bulk data operations during low-usage periods.

Permissions get weird with complex org structures. External collaborators, varying repo access levels, and enterprise SSO create edge cases where people can't see project items they should have access to. Test permission scenarios thoroughly.

What Success Actually Looks Like

After 8 months, our main project has:

• 3,200 active items (performance is still acceptable)
• 8 custom fields (we use 5 regularly)
• 12 automation rules (6 are actually useful)
• 85% team adoption (vs 40% with Jira)

Key indicators you're doing it right:

• People update project status without being nagged
• Sprint planning takes 30 minutes instead of 2 hours
• Your PM stops asking "what's the status of X?" constantly
• Developers don't curse when they have to check project boards

Red flags that indicate failure:

• Constant manual updates to keep boards accurate
• Team members bypass the project system for "real" tracking
• Automation creates more work than it saves
• People ask for Jira back

The biggest lesson: GitHub Projects works well when it matches your team's existing GitHub workflow. If you're trying to force elaborate project management processes onto a simple dev team, you'll fail. Keep it simple, focus on reducing friction, and add complexity only when the team actually asks for it.

The Real Success Metric: Developer Happiness

Forget velocity charts and burn-down reports. The ultimate measure of GitHub Projects success is simple: do your developers groan when they have to update project status, or do they just do it automatically because it's frictionless?

After a year of implementation across multiple teams, the difference is stark. Teams that succeeded with GitHub Projects integrated it into their existing Git workflow. Teams that failed tried to replicate their Jira complexity in a tool designed for simplicity.

The best implementations feel invisible - project updates happen as a side effect of normal development work, not as additional overhead. That's when you know you've got it right.