By Kim Bryant
For those of you gung ho to get your geek on (and I mean that in the nicest possible way), this post is designed to give you the skinny on some of our basic Jira configurations. Not much philosophizing, but chock full of grainy-detailed goodness. Dig in!
User Types (Roles)
We have 5 main user types, what Jira calls "roles:" Component Lead, Project Administrator, Project Manager, Resource (developers, UX and designers), and Users.
Component leads are also usually Product Owners. They are responsible for specific products, driving the road map, and the work prioritization of a specific product. In Jira, they triage, enter, track and ensure completion of tasks. As I mentioned in my first post of this series, Jira automatically assigns tasks to component leads, though some users have the ability to change the assignee to someone else.
Project Administrators own a specific Jira project and have more permissions than most user roles. They can create components, assign component leads, set default assignees to a component, create new versions, and release and archive versions. For obvious reasons, there are only a few people with this role.
Project Managers are project managers at NPR, not just in Jira. They need some specific permissions in Jira that allow them to execute a handful of actions usually only given to Jira Project Administrators. For example, they can force tasks through specific workflow states, but they can't create or release versions.
Resources carry out the actual work required by the issue and include staff from the user experience, design, and development groups. Resources are usually assignees in Jira.
Users are our most basic role and usually stakeholders, managers, and business owners. They use Jira infrequently, and most often for logging bugs or enhancement requests.
NPR Jira's projects and similarly crunchy nuts and bolts, after the jump.
Projects and Components
Jira calls groups of like requests "projects," which drives me bonkers because it's one of the few things I really want to change in Jira and can't. Ours are listed below in rough order of magnitude from "big picture" to tasks only specific groups will care about.
Digital Media Projects -- Contains medium to large projects that product owners, resources, and Digital Media managers need have on their radar (basic Jira users don't see this area). A Jira filter is used to generate a list of active, on hold, and proposed items for discussion in a weekly project status meeting.
Digital Media Requests -- Familiarly known around NPR by its Jira key, WWW, this is the big bucket where every user can submit requests and is the most heavily-trafficked section. Product owners and managers are watching for incoming requests to triage and teeing up items for future planned releases, resources are managing their work queues and reporting progress on their tasks, reporters are logging and verifying whether or not issues have been fixed, and administrators are cleaning up stragglers and misplaced items. There only two types of issues in this project: requests and immediates. The latter is for reporting issues that are urgent but not emergencies; we aim for someone to provide a substantive reply to an immediate ticket -- if not a fix -- within four to eight business hours.
Components for Digital Media Projects and Requests are very similar and we try to keep this list easy to use and as short as possible: API, blogs, contact forms/help, mobile/portable media, music, newsletters/viral, NPR Community, overall site, player/streaming, registration, Seamus (our content management system), search, sponsorship, strategy, and Web analytics. The only difference is that each project has one additional component: Digital Media Projects has "strategy" and Digital Media Projects has "editorial graphics."
Software -- This area is for the use of the Applications team, though all Jira users have at least read-only access. The really technical tasks show up here -- often gobbledygook to non-technical folks, but it allows a complex Digital Media Request to be mapped to many fine details in Software and those fine details to be mapped to our code base (via SVN). For example, someone might log a WWW task to (ahem) migrate databases from Oracle to MySQL. That one WWW task could be linked to multiple, intricate Software tasks performed by many resources.
Components: aggregations, blogs, crowd, miscellaneous, music, Seamus, story, www
Sys Admins -- As you might guess, the Digital Media team's system administrators use this area. We've allowed all users to enter tickets here because it includes tasks like setting up access to file servers for editors. Remembering this can be a bit challenging for those who use Jira rarely, though, so it's possible this area will evolve into something more like the Software project: a Jira project where the sys admin team can track and enter their own tasks.
Components: Atlassian dev tools, Confluence, Crowd, Jira, SVN, www
Application Errors -- this project collects automatically-generated errors from servers and creates Jira tickets. Jason Grosman wrote an inside npr.org post about this cool process. You can read more about it here.
We use a straightforward, 3-digit system in the Software project for managing releases. The first digit is for a major release, the second for a planned release (usually every 2 weeks), and the last digit is for emergencies. These versions are tagged and mapped to other tools we use, like SVN, Crucible, and Confluence. The Digital Media Projects project doesn't really have releases in the traditional sense; because we're using it as a portfolio roadmap, we use fiscal year quarters to indicate roughly when a project will launch. The Sys Admins and Application Errors projects don't require releases, but it's easy enough to add them if we need to in the future.
The Digital Media Requests project has the most complex versions, hands down. We created a cheat sheet for the Jira users who can see this field.
1. Unknown -- The default selected when most users create a Jira issue. An issue will not usually stay in this version.
2. Production requests -- Doesn't require a backend code release from the application team (e.g., CSS changes, editorial graphics)
3. Backlog -- A pool of potential work from which product owners pull candidates for planned releases. These issues sometimes require more thought or strategy before they can be implemented and often require a backend code release. They may be larger in scope/difficulty, or smaller, more obscure, or difficult to reproduce. If an issue is in the backlog, a resource is not fixing it yet.
4. Lobby -- Short-term holding pen for issues being considered for the next planned release. These may be returned to the backlog or moved into a planned release, depending on how the group of product owners prioritizes the lobby issues. If an issue is in the lobby, a resource is not fixing it yet.
5. Planned release -- Regularly-scheduled backend code releases. Items for these releases are chosen by product owners and key stakeholders. They are given names in alphabetical order. (e.g., Dino, Elmer, Foghorn, Gideon). If an issue is in a planned release, a resource is actively addressing it.
6. Emergency -- A backend code release to address one or more issues that are so urgent or badly broken, we cannot wait until the next planned release to push them live. An emergency release is followed by a 3-digit number to help the applications team map it to the code base (e.g., emergency 2.0.4, emergency 2.5.1). If an issue is in an emergency release, a resource is actively addressing it.
Some of our plugins and additional functionality:
1. GreenHopper -- Agile tool recently purchased by Atlassian. Allows for drag-and-drop story cards and burn-down charts. We're hoping this is more tightly integrated in a future Jira release, but it's a great start. We used the ranking portlet heavily during the npr.org redesign project to figure out tasks had to be done before others. Now it's a tool for roughly ranking the relatively importance of our Digital Media Projects.
2. Jira calendar -- Displays past and future release dates in a calendar view, which we post by default on our dashboard.
3. Jira Timetracking -- Enables sophisticated time tracking, including initial LOE estimates, "time remaining" adjustment after a task is in progress, and stop/start buttons for real-time tracking. The last item is unrealistic for NPR's responsive culture (e.g., important news pops up unexpectedly and we have to do stuff to support it), but it's still pretty nifty if you want to track a solid block of coding effort.
4. Jira Charting -- Used to display metrics and stats, especially on the custom metrics dashboard we designed for managers.
5. Bulk Move Restore Fields -- A lifesaver in the early days of our using Jira, it allowed us to restore versions and components after we migrated a horde of issues from one project to another. Repeatedly. Good to have in your back pocket if you are allowing rapid evolution of Jira as you discover how your organization uses it in the real world.
We're still tweaking how we use Jira, and we always will. We recently discovered that we needed to add a workflow status to one of our projects so it's clear when the next step can begin. Also on the horizon is an upgrade to a more recent version of all the Atlassian tools. We're currently rock-solid on Jira 3.13.2, but there are definitely some bells and whistles we're itching to get our hands on. Complex searching, easier-to-customize dashboards, and a history that follows you to wherever you're logged in are just a few of the features we're looking forward to trying in version 4.
categories: Administrative Stuff