← All articles
  • Scrum
  • Product

ZenHub alternatives: what to use when two repos is not enough

ZenHub's free plan gives you 50 users but only 2 repositories and 250 issues. Here are the alternatives for GitHub teams, sorted by how tightly you want to stay coupled to GitHub.

5 min readThe Scrumpy team
ZenHub alternatives: what to use when two repos is not enough

ZenHub's free plan gives you fifty users and two repositories. Read that again, because the numbers are the wrong way round compared to every other tool you have priced this week. Everyone else runs out of people. ZenHub runs out of code.

For a team with one monolith, that is fine and possibly free forever. For a team that split the API from the web app eighteen months ago and added a workers repo in spring, it is a wall you hit in month two, with fifty seats you were never going to use.

That mismatch is the reason most ZenHub searches happen, so it is worth sorting the alternatives by the question that actually decides it: how tightly do you want sprint planning coupled to GitHub?

If you want to stay inside GitHub entirely

GitHub Projects is the obvious answer and a genuinely improved one. It supports iteration fields for planning week by week, including breaks, along with start and target dates. Its insights view lets you build and customise charts from your project items. It comes with GitHub rather than as a separate bill.

The trade is that it is deliberately unopinionated. There is no sprint goal, no built-in scrum ceremony, and you assemble the process from fields and views yourself. There is also a cap of 50 fields per project, which sounds generous until a team gets enthusiastic about custom fields.

If your engineers live in GitHub, your issues are already there, and nobody outside engineering needs to plan with you, this is the cheapest good answer and you should try it before paying anyone.

If you want to stay coupled but need more room

Paying for ZenHub is the boring option and sometimes the right one. Teams is $4.99 per user per month billed yearly, or $7.50 monthly, which lifts you to 10 workspaces, 50 repositories and unlimited issues.

Nobody writes a blog post recommending the incumbent's paid tier, which is exactly why it gets skipped. If ZenHub fits your process and the only problem is the repo cap, five dollars a head is cheaper than a migration in every sense that matters.

If the coupling itself is the problem

This is the group we hear from most, and the tell is a person rather than a limit. It is the product owner who does not have a GitHub account, or the client who is never getting one, or the designer who would like to see the sprint without learning what a pull request is.

Once sprint planning lives on GitHub issues, everyone who participates needs to be in GitHub. That is a reasonable trade for an all-engineer team and an increasingly awkward one for everybody else. We wrote separately about what that coupling costs you over time.

The alternatives here are the standalone scrum tools. Shortcut is free up to 10 users with native Iterations and a developer-shaped interface. Jira is free up to 10 users and does everything, at the price of doing everything. Scrumwise is a focused scrum tool at $9 per user per month, $7.50 annually.

Where Scrumpy fits

We are $9 per editor per month, $7.50 billed annually, one plan with every feature, and a 7-day trial with no card.

The specific reason ZenHub teams end up here is the seat model rather than the features. View-only people are free and unlimited, so the product owner, the client and the designer who all just want to watch the sprint cost nothing and do not need a GitHub account. On a team of five engineers and four watchers, that is five seats instead of nine, and four people who can finally see the board.

Your issues come across through CSV export from GitHub with status mapping during the import, so the migration is an afternoon. There is no repository concept at all, which is the point: your work is organised by team and sprint, not by where the code happens to live.

The honest limitation is that we do not sync with GitHub. No two-way issue mirroring, no branch or pull request status on the card. If that link is load-bearing for how your team works, ZenHub and GitHub Projects both beat us and you should stay with one of them. That is a real trade and it is the first thing to test in a trial, not the last.

Choosing

Everyone is in GitHub already and nothing external is pushing you: GitHub Projects, free. Only the repo cap hurts: pay ZenHub, it is five dollars. People outside engineering need to plan with you: a standalone tool, and then the deciding question is how many of those people only need to watch.

If that last group is most of your stakeholder list, try the board with your GitHub CSV in it and add the watchers for free. Worst case you learn in an afternoon that the GitHub link mattered more than you thought, which is a useful thing to find out cheaply.

Frequently asked questions

What are the limits on ZenHub's free plan?

ZenHub's free plan allows up to 50 users but caps you at 1 team workspace, 1 connected GitHub organisation, 2 repositories and 250 issues. The Teams plan lifts those to 10 workspaces, 50 repositories and unlimited issues at $4.99 per user per month billed yearly, or $7.50 billed monthly.

Is GitHub Projects a good ZenHub alternative?

For teams that want to stay inside GitHub, yes. GitHub Projects supports iteration fields for week-by-week planning, start and target dates, and customisable insight charts, and it is included with GitHub rather than billed separately. It is limited to 50 fields per project and is less opinionated about scrum than a dedicated tool.

Why do teams leave ZenHub?

The two most common reasons are the repository cap on the free plan, which small teams hit quickly when they split services across repos, and a preference to stop coupling sprint planning to GitHub issues entirely so that non-engineers can take part without a GitHub account.

Can I move my ZenHub issues to another tool?

Yes, because ZenHub stores its data on GitHub issues. Export your issues from GitHub to CSV, then import that CSV into the new tool and map each status onto a column. Scrumpy reads the file, previews it before creating anything, and lets you set the status mapping during import.

Keep reading