Writing software at any kind of scale, with any kind of schedule means you’ve signed up for the world of tradeoffs. This isn’t a bad thing, in fact, it’s how many organizations get their jobs done every single day. However, often times the criteria for making tradeoffs aren’t made explicit, and can be detrimental if not understood by all people involved.
Some Standard Priorities In Atlassian’s JIRA
Tracking bugs, and triaging them actively is incredibly important, however most tracking tools offer a simple lens for priority by default. A problem comes in here because each team could (read: does) have a different definition than your team about what priority actually means. So why do we even bother using this field?
In an ideal world, priority is perfect. A clean deterimination of when we should actually start working on this problem to make sure all of our users don’t see it, however, writing software for a product that goes to humans is never going to be an ideal world. Let’s try to pull apart what priority actually means, and maybe what we could use instead.
Problems With Priority
My main problem with priority is that it’s actually an opaque, derived value. Whoever sets the priority on a bug went through some internal process in their mind of figuring out that bug X is a release blocker, and needs to be fixed ASAP. Hopefully the person assigning priority has been clear and open about how they are making the decisions, but I’d guess more often than not, it’s a mix of gut feeling and maybe, current mood.
With this internal-only model of priority, the person assigning these values must endlessly try to communicate why they assert that a given bug is worth trading off now, or not. Even worse, if that person is out, others must figure out What Would That Person Rank This (WWTPRT)? Maybe they get it right, but maybe they don’t, the opportunity for them to misunderstand the process is incredibly high.
My second problem with priority is that they aren’t fixed! Here are instructions on how to add new priorities to your JIRA project, which I’m sure has some valid cases, but will just push every team further from having a shared understanding about priority. Understanding of what these values mean is now at an all time low, and ripe for organizational confusion, tickets not being done, and users being very unhappy. So how do we get to a point where everyone can be on the same page?
Factor Out Priority Variables
When making the big decision around priority for a given defect I feel that most internal processes will likely include at least two things:
- What kind of defect? — The spectrum of defects is very large, where does this fall in that spectrum as best as I can see?
- What is the frequency of the defect? — Does this happen every time, some times, some times for some users, very infrequently, only when the moon is full?
These two variables (and maybe more for your organization) are key in decoupling the gut decision from the right decision. Even more valuable, this can give you repeatability in determining what is still outstanding for a release in order to ship. Priority is a roll up of these values, but even now that the variables are broken out, we need to actually define how they rank together.
The Chart
An example of defect frequency vs defect type chart
The chart is where your organization can help decide the priority of defects across all projects. This approach was passed down to me from one of my first bosses Lori, but it’s so rational that I don’t think it hit me until many years later. This chart is the final step in removing the gut feeling from the decision making process of classifying defects, and ensuring your making the right tradeoffs as defined by your organization.
Clearly, we see there are some typical priority values in the center of the chart, but how we get to them isn’t with guess work, it’s with the data we created in the previous section. The chart for each company may look a little different, but that’s fine, as long as everyone agrees to use the same chart.
Does this mean that cosmetic issues won’t become release blockers sometimes? No, because maybe they look pants (another term I learned from Lori 😀) and you should just fix them, and that’s fine. No process should be inflexible, but they all should have some structure.
This classification system also gives you the benefits of now having structured data around what kind of defects you have which could help reveal other problems in related processes, as well as the ability to build reporting around this new data available in your bug tracker.
Could this be the right way to keep your collection of bugs, features, and the like organized? Maybe, maybe not, it’s really whatever works for your organization. Will this give you more infromation about what’s going on in software projects? Hopefully, having more structured data around this bug tracker information can only help your organization make a more informed decision on which trade offs to make.