How we hacked JIRA, and so can you
JIRA is fantastic, and is used by over 35,000 customers – a testament to its flexibility. There are many plug-ins that extend this functionality, and you’d struggle to find a use case that isn’t supported in general.
Like many tech companies, we use JIRA for issue and project management, which has become increasingly important as our engineering teams now sit on two continents and span six time zones. And while JIRA has been a reasonably good tool for handling those tasks, we had a hunch that JIRA could do even better.
The problem with one size fits all:
Any application, be it technology, sport, or medicine, is built for the general use case. It’s the key to becoming profitable, and it’s what allows for easier scalability and performance. The downside is that the application is either swamped with options (99% of which we have no use for) is aesthetically displeasing, or requires a large amount of effort to customize. In fact almost all large software companies have teams dedicated to customizing their offerings to high value clients, or those willing to pay.
In most cases, the common user is left trying to find off-the-shelf products that suit their needs (beware the “easy dashboard for anything” promise). In my case, I manage a team of 12 developers, and we challenged ourselves to quickly (with a budget of one week) tackle two common problems within JIRA:
- Quickly checking everyone’s workload.
- Quickly viewing the roadmap of the next few months.
Challenge #1: What is the workload of each team member this week?
As a manager, one of my roles is to act as a load balancer for the team. I need an easy way to quickly see which tasks people are working on, so I can assign new tasks and reprioritize existing ones. For this challenge we used the JIRA Agile view as inspiration:
The problems with this view are:
- It’s hard to get to (requires some navigation around JIRA).
- It’s very tall (lots of scrolling required).
- Issues are grouped either by Epic or User – it’s impossible to do both.
- Colors to represent business units. These are selectable at the top, so if I want to see who is working on Analytics Projects, I can toggle this easily.
- Comment counts to show issues under discussion.
- Closed/Open issues. This is a toggle that causes the boxes to flip over, revealing the recently closed issues.
- Links back to the original issues on JIRA.
- Holiday/Illness/Leave toggles. Double-click on a person’s avatar, then toggle their view to reflect the absence type.
- API caching. The JIRA API on our installation is too slow to render this page in real-time. Instead we query the API (using JQL) to retrieve issues that have be recently updated. We repeat this every minute and store the results in a local MySQL database. The result is a page that loads instantly.
Net result: The team continues to use JIRA for their day-to-day management, while I, and other managers, are able to quickly get the holistic view we’ve always wanted. Plus, it’s visually stunning!
Challenge #2: What is my roadmap for the next few months?
Whether it’s the executive team approving my budgets, or the marketing team looking ahead, I’m often asked to provide both short and long term roadmaps, along with details of recently delivered projects.
The inspiration for this came from the JIRA roadmap feature:
The problems with this view are:
- It’s hard to find in JIRA – remember this view is designed for non-developers.
- Visually it’s very empty.
- JIRA assumes you are working on one big project, so you can’t group versions together.
- There is no way to add a free text “status” so people know where the version stands.
- Info icon to reveal a longer description of the version.
- Number of tickets remaining alongside number of stories being worked on.
- Indicator as to who is working on which version (in case somebody wants to get in touch).
- Indication (through color) of whether a version is released, in QA, or still in development.
- Updates – We again cache the version information in a local MySQL database. Here we added a new table called Version_Updates which has three fields:
- Version ID – used to join back to the Version table.
- Update – free text, added ad-hoc or during weekly team meetings.
- Timestamp – so we can keep a full history of updates and display them in descending order.
Net result: We now use this view as our weekly update notes to both other teams and our executive team. Questions on priority, versions, and releases are now routed directly to those involved, improving internal communication.
We started this project with the belief that as developers, we could build small applications quicker than we could customize anything. Not only has this been confirmed, but it also has brought the team together in ways I hadn’t foreseen. Because we were our own customers, we were forced to have discussions around design, usability, workflow, and technical decisions that involved each member of the team.
For example in the team view, we show closed tickets on the back of each card, with a smooth flip animation to reveal. We used jQuery plugins where possible and each time we picked a plugin we found ourselves suggesting uses for that plugin in other projects we had worked on.
This approach was far more cohesive, overall, as we were completely unbound (we could use any technology we wanted, and we owned all design decisions). My recommendation coming out of this project is to trust yourself when it comes to solving problems, and be creative when it comes to solutions. Whether your preference is Excel, PHP, or C++, you can often build something that suits your needs, and out-performs off-the-shelf software. Your needs are unique after all, so your specification and use case should be unique, as well.