Jira vs GitHub Issue Tracking

Rory Dwyer
Oct 6 · 7 min read
Image for post
Image for post
Photo by Headway on Unsplash

I recently joined an established software development team in a large enterprise who exclusively used GitHub for issue tracking. From a developers perspective, it made sense. GitHub becomes your one-stop shop for tracking, version control and source code management.
If it ain’t broke, why fix it?

The Product Owner and I talked about backlog visibility and found this was one of the major challenges with the current setup. As the team maintains a number of services spread across multiple GitHub repositories, there was no single board to view and refine a combined backlog. Another challenge was that there were no estimations or story points, with more of a gut-feel approach on what could be completed in any given sprint.

After a few retros, we noticed some common themes occurring. So we decided to do an agile baseline health-check to further validate where we could improve. We individually scored our team on various agile fundamentals then had a big retro to review the results. Some of the common themes we struggled with were, in part, directly related to those limitations in our issue tracking mentioned earlier. Clarity on the product vision and backlog management was an issue, which a single backlog view could improve. Sustainable pace was an issue, which estimations and understanding our velocity could help with. The quality of user stories was also an opportunity for us to grow, which would require discipline — but perhaps the right tool could accelerate the process!

Image for post
Image for post
We projected our agile health to improve by at least 40 stonks with the right issue tracking tool

For the record, our target areas could be tackled in lots of ways! But for this article, we’ll focus on issue tracking and the backlog.


Aside from not really being a traditional backlog offering, a limitation of the project board is that it is not suited to larger projects and teams with a higher number of issues. In those environments, you may not want to use automation to add all new issues to the board, or it will get cluttered quickly and lose clarity. Therefore, you’ll be adding cards manually using the Add Cards pane. This offers no drop-down menus or auto-fills for simplified searching, so if you’re running a lot of repositories and issues this becomes a bit daunting.

Image for post
Image for post
Easy to setup, but has it’s limits

Another limitation of GitHub’s project boards is that a maximum of twenty-five repositories can be linked to one board. For most teams this isn’t a problem. However, it’s worth considering how your team and product might grow over time when making a choice.

Whilst I’m sure there are many ways to customise your GitHub, our team wanted a light-touch setup. Those who have worked in large enterprises will know the challenges in customising your operational tooling, with approvals and dependencies likely to slow down any significant change.

At least it’s super easy to get rolling with.

Alternatively, Jira could take slightly longer for that initial setup but may offer more value overall.

We decided to go with Jira for a few reasons, one of them being the backlog view. We added quick filters to allow the PO to switch between the combined backlog view of all issues or to view issues only for a particular service. While at the same time, developers could bookmark the Jira board with the quick filter(s) for their current workstream already selected — saving them from the noise of unrelated issues.

The backlog view in Jira allows us to drag and drop issues between sprints and backlog easily. We can drag priority tickets to the top of the backlog to visualise and plan how the next sprints will look, ensuring our refinement ceremonies are more meaningful.

Image for post
Image for post
Clean and crisp backlog

Issue Fields

On the second problem of user story quality; as touched on earlier this would require discipline from the team, but could also be helped with by the right tool. By simply enabling the Acceptance Criteria field in our Stories in Jira and making it mandatory, we were reminding ourselves to meet some minimum requirements on all of our Stories. This was a basic example of prompting the user, but plenty of Jira’s built-in fields could be used to guide users in the right direction.

Image for post
Image for post
Great job, me!

Another benefit with issue content was using Epics to group Story issue types. Where previously in GitHub, we were trying to loosely group related tasks using combinations of labels or milestones, the Epic issue type allowed us to create a high level parent issue with some information around the overall goal of that feature or enhancement. This is far superior to a GitHub label, for example, as it allows information such as acceptance criteria or a business-level user story, to be held at the top level Epic — as well as allowing the Epic itself to transition through a workflow.

Image for post
Image for post
Epics are awesome. And epic!

Migrating from GitHub to Jira

A limitation is that the issue comments don’t come back in that API response; instead you’ll need to make a second API call for each issue to another endpoint for comments. As our comments were low volume and not worth the extra effort, we simplified the approach and instead made the CSV template a tiny bit fancy by concatenating the original GitHub issue link into the new Jira description to be imported. That way if anyone wanted to check the original link for comments it was right there in each Jira ticket.


When would Jira work best for issue tracking? From my experience, when directly comparing to GitHub, Jira gets the chocolates in most categories. Especially in large enterprises where transparency and reporting are fundamental. Yes, it can take longer for initial setup depending on your requirements, such as for more complex workflows. However, if you need a lightweight setup there are built-in workflows.

One downside is that you need some customisation to link Jira issues directly to GitHub pull requests, which developers may bemoan when comparing to GitHub.

Hopefully this information helps as you consider the needs of your team. Good luck!

I have no affiliation with Jira or GitHub. I’m just a nerd for organisation.

Reach out to hello@momenton.com.au to understand how Momenton can help your organisation and how we can help mature delivery of your products.



Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store