How we Prioritize with Trac

For almost three years we’ve been using Trac as a project and issue management application in our work with [[Yankee]]. This after many years of experimenting with other systems, some homebrew and some open source, none of them satisfying.

Trac hits the sweet spot for our team between comprehensiveness and brevity (nobody wants to fill in a 3-page form just to submit a bug report, but we do need a basic template of information to be efficient).

What this means, day-to-day, is that any work that any member of the web team, inside Yankee or outside, is going to take on gets an “issue” (aka “ticket”) created for it, using a web form that looks like this:

With any tool like this, one of the key pieces of information is how work gets prioritized (it’s the “Priority” field in the form above). And how this is handled generally depends on whether you’re on the “client” or the “server” side of the issue – the person who needs the work done or the person who’s going to do the work.

The simplest way to handle this is by simply assigning a ranked priority: priority 1 jobs get done before priority 2 jobs, and so on.

The problem with this is that while it allows for relatively fine-grained control on the client side, it tends to make programmers and designers feel “boxed in” by a strict order of operations. (Programmers and designers, as a rule, don’t like to be told “okay, work on this now.”)

To deal with this, we’ve come up with a system that gives the “clients” enough information about when their issues will be addressed (right now, soon, someday, never) and gives the “servers” (programmers, designers, QA people) enough flexibility to have a self-directed workday with some variety.

We’ve evolved a set of priorities with Yankee that work for our team; to keep things as simple as possible we add new priority settings with some reluctance, and only if everyone’s in agreement. Here’s what we use, and what each priority means in practice for us:

Discuss at Scrum: We have a weekly conference call with all members of the team present, to go over the issue queue, and assigning this priority means “we need to be sure to have a discussion about this,” generally because there’s some question about the issue or its priority. This is the priority we added most recently, and it’s saved us a lot of time at our weekly call because we don’t need to review the status of every ticket, only the ones here.

Critical: Drop everything else and work on this right now: there’s a problem with code, design or infrastructure that’s breaking something; we work on critical tickets to the exclusion of everything else.

Need Feedback: Generally a place for issues to go after work is essentially complete but before closing them. We put issues here when the person doing the work is finished, but before the issue is closed, if there’s some question as to whether the issue was really addressed, or if further information is needed. It’s a sort of short-form way of handling “Dave, please take a look at this and if everything is okay you can go ahead and close the issue out.”

Specific Date: If something absolutely has to happen on a specific date – a campaign released or a contest turned off, for example – the issue goes here. We have a “due date” field for issues that need to be completed by a certain date, this is for situations that are time-sensitive and need to happen on a specific date. It’s the least concrete of priorities, but it’s served a useful purpose for us.

Blocked: Issues go here if work can’t move ahead, either because some amount of time has to pass – we implement a change and need to wait a few days to see whether it worked – or because some third-party needs to take action before we can proceed.

In Progress: I’m working on this right now.

Two Weeks: We have a two week development cycle, and so work to break down all projects into bite-sized chunks of 2 weeks or less. Giving an issue this priority means “we’ll work on this issue during the current two week cycle” and it’s really the heart of the prioritizing system from the “doing the work” side of the equation because it allows us to treat all items with this priority equally, creating a sort of “smorgasbord” from which we can chart our daily work routine.

Coming Soon: An issue that’s “on deck” for a “two weeks” priority, but that we’re not ready to start work on yet. There’s an ever-present danger of issues languishing here forever, and if there’s a weak point in our system it’s that we need to be more disciplined about revisiting issues here regularly to prevent that from happening.

Accepted: An issue that we’ve agreed will be worked on someday, but that’s not being worked on right now, and it’s “on deck” for work soon. At worst this is where issues go to die, but we’ve been pretty good at either marking an issue as “won’t fix” and removing it entirely if we know we’re never going to work on it, or putting it here if we know we really are going to work on it, just not right now.

Proposed: All newly created tickets that aren’t “critical” start here, get discussed by the whole group at our weekly meeting, from which they either get rejected (marked as “won’t fix” or “duplicate”) or assigned another priority. Having this be the single point of entry for tickets is both a good filter and means that everyone’s eyes are, at least at the very beginning, on every ticket that gets created.

This list of priorities has evolved over time – the last item on the agenda of our weekly call is a “process review” where we talk about things like this. The most important aspect of the system is that there’s a shared understanding of what each priority means (so that, say, “this is really important to me” issues don’t get mis-prioritized as “critical”); the most challenging aspect is convincing everyone on the “client” side that when we say “two weeks,” it really means “two weeks” to the point where they can be comfortable enough to trust the system and not develop a out-of-Trac side-system for maintaining the “real” priorities.

When I compare “life with Trac” to life before, I can’t say enough about how it’s improved our long-distance working relationship with Yankee, and, I think, the efficiency of the web team inside and outside Yankee as a whole.

I see having some issue management that’s not “categories in my private email inbox” is a vital part of every project I take on now (to the point where I’ve sometime wished for “Trac@Home”, a system where I could maintain issues like “get glass for front door fixed” and “pick up milk”).