Jira: You Say Godzilla, I Say Gojira : Inside NPR.org When we looked at what we needed to succeed with our culture and evolving development process, Bugzilla was like Matthew Broderick, CGI-slick, prettied-up, simplified sci-fi. We needed old skool, hard core, eat-the-train-cars-and-stomp-on-the-citi...

Jira: You Say Godzilla, I Say Gojira

The Marine Iguana, while adept at foraging in water, would probably make a poor issue tracker. Phil Frank hide caption

toggle caption
Phil Frank

The Marine Iguana, while adept at foraging in water, would probably make a poor issue tracker.

Phil Frank

Bugzilla, Gojira... issue tracking software manufacturers must have a thing for Japanese sci-fi. All monster-lizard monikered apps are not created equal, though, and our challenges hardly resembled Hello Kitty.

The Digital Media Applications team used Bugzilla for about 4 1/2 years to file bugs, note future enhancements, and keep a general record of past fixes. Besides the Digital Media technical staff, some editors and interns also filed bugs in Bugzilla. Careful thought went into designing the fields so the information gathered would be as complete as possible, including details on platforms, browsers, and components. Items were selected from Bugzilla for upcoming releases, but the product owners often kept separate lists of "their" bugs in Excel or Word so they'd remember what was most important to them and their area.

By January 2009, Bugzilla had become a giant to-do list that kept growing exponentially. There were 3,000 open bugs when we started prepping for the switch to Jira, and many of those were no longer valid. It was hard to search for specific issues, and non-technical staff members were intimidated by the number of choices in field drop-downs. Bugs were often missing key information as a result and duplicates were accidentally missed. When developers added comments or a request for details to a bug, it was often overlooked or ignored because Bugzilla emails were sent to a large distribution list. Before a release, we had to contact reporters in a separate email or call them so they'd know when their bug was fixed and ready for them to test.

Why we decided to go Jira (please groan at bad pun now), after the jump

When we looked at what we needed to succeed with our culture and evolving development process, Bugzilla was like Matthew Broderick, CGI-slick, prettied-up, simplified sci-fi. We needed old skool, hard core, eat-the-train-cars-and-stomp-on-the-citizenry sci-fi (which happens to be the preference of the Atlassian Jira team, coincidentally.) Jira delivers:

1. Awesome permission levels: We're able to show different types of users only what they need. Editors, who belong to our "basic user" type, see the bare minimum fields needed to report an issue, which is important since editors rarely use Jira and we want to make it as easy as possible for them to file a ticket. "Resources" have access to a few more fields, like version, and they can move an issue through some of its lifecycle when they are the assignee. "Product owners" have permissions tailored to their responsibilities, too. For example, if they know an open issue is a duplicate, they can mark it as such and move the ticket state directly to "closed." Like Bugzilla, Jira sends automatic emails when an issue is updated, but we're sending only to reporters, assignees, and watchers (the equivalent of cc'ing).

2. Integration with other developer tools: We added several applications in the Atlassian suite to our toolbox, including Confluence, a wiki we use for technical and product information. Confluence macros pull in a wide range of Jira data; we use it to display lists of Jira issues in a specific release, for example. We've configured Crowd, Atlassian's solution for single sign on (SSO), so that our users log in to the Atlassian suite using their existing NPR Active Directory account. We've extended Crowd so that we can log in the same way to our in-house content management system. We're also using Atlassian's code review tool (Crucible) and source code repository (FishEye). Our commits to SVN include Jira issue numbers, so when we're in Crucible we can easily click links to Jira tickets and see details on code changes, as well as see what Jira tickets affect which files.

3. A smorgasbord of custom configurations: We're able to serve high, medium, and low-level details depending on the user type and needs, and we've set up some interesting plug ins, business rules, and processes. We configured a dashboard metrics view for managers. We've designed different workflows for each type of Jira project ("project" is a Jira term for a bucket of like requests). We turned on time tracking, not to Big Brother our staff and squish every last ounce of productivity out of them, but so we can put an estimate on requests and see how long it actually takes us to complete the task. This should improve our LOEs in the long term and sets expectations with requestors in the short term. I could talk about custom configs until the cows come home, but most folks start mooing for mercy after five minutes. If you want to know more, comment on this post and I'll reply.

4. The ability to track as much of our work as possible: We've got production requests (no backend release required), full-blown projects, and strategic work for designers and IAs that takes weeks or months. We have infrastructure enhancements, system administrator tasks, and graphic requests for stories running in 24 hours. All this work is now logged and tracked in Jira, and we're getting better at seeing the overall picture of requests. Different product owners are starting to group related issues together when asking for a fix. For example, the search and blogs product owners recently found four issues that, if done together, would take less time than if they were executed separately.

5. Statistics to make an ops manager weep for joy. We track trends like number of issues submitted vs. resolved in a thirty-day period, which can help us spot spikes that may indicate problems with a specific application. Another area we watch is workflow states per resource group. As of the time I polished this post for publication, our small but mighty User Experience team had 121 open issues, so we may need to set expectations that these requests could take longer to address. We can use burndown charts via GreenHopper (an Agile plugin that Atlassian recently purchased) for some projects to track and predict if we're going to complete all the work for a given release by the deadline. We're still getting our feet wet, but Jira stats are going to help us take corrective action sooner and plan better.

In my next post: some of the down-and-dirty fine points on how we've set up Jira at NPR.