Categorizing bugs and issues can be overwhelming at times and may seem like an extraneous step at other times, but a carefully considered set of categories can enhance your workflow by making it easier to group issues, manage workloads, and gain project insight. The key is understanding the strengths and weaknesses of categories.
Grouping & Filtering
The most basic goal of categories is to help group related issues. This can help make it easier to find duplicates and patterns within areas of your application. The sibling of grouping is filtering. Grouping’s main benefit is to serve as a way to quickly view a batch of related issues without the distraction of dozens of unrelated issues. 1
For instance, let’s say you’re about to sit down to work on your application’s user management area. If you have a category specifically for issues with the user management area, you could filter your issues down to see what else needs to be fixed while you’re in there. This can help you isolate relevant work to help kill two birds with one stone or identify other things you can fix when you’re done with your current bug. This can help increase developer efficiency as well as increasing the likelihood of catching duplicate or related issues.
Areas of Responsibility
One of the key considerations for organizing categories is accountability or areas of responsibility. Categories work best when they loosely correlate to the individuals responsible for the various areas of your project. Sometimes that accountability aligns closely with modules, but other times it aligns more closely with skillsets or specialists.
The benefit of grouping categories based on areas of responsibility is Sifter’s option to associate a default assignee with each category. 2 This ensures that issues are always assigned to the relevant person, without requiring the reporter to know who handles each kind of issues. They can just choose a category and Sifter will take care of the rest. This can help facilitate triaging issues and make life easier for everyone involved.
There are two slightly different approaches you can take to keep categories aligned with the individuals most familiar with that area of your application. The first is your application’s modules, and the second is the functional layers of your application.
Over the years, we’ve found that the one almost universally best way to categorize is based on modules. This creates the best scenario for identifying related issues, and it helps keep it crystal clear which category is right for a given issue.
Your categories may look something like this basic set:
- User Management
- Email Notifications
- Help Docs
Depending on your team, it may make more sense to group issues based on skillset or the type of work. This often makes it easier for multiple developers to share similar work. The only downside is that if you have non-technical team members, this can make it harder for them to know where an issue belongs, and it may increase the need for triaging.
For instance, if you have a team of five developers each with their own specialty, you might have the following categories:
- Design & Usability
- Front-end Development
- Back-end Development
Number of Categories & Over-classification
Too many categories, and you end up with only one or two issues in that category. Too few categories, and you end up with hundreds of issues in the same category, defeating the purpose of organizing them. So how do you find the right balance? If you go to manage your categories and you see that some categories have less than three issues, those additional categories are good candidates for consolidation or removal. 3
Few things are more counter-productive with categorization than over-classification. A project that’s likely to have 50-100 issues won’t need many categories. Too many categories creates more choices and becomes a little more overwhelming for the folks reporting issues. It also increases the likelihood that an issue could belong in multiple categories, further confusing the issue. Let’s go crazy with an extreme example. If you find yourself with thirty unique categories for thirty individual issues, you won’t really have accomplished or grouped anything. It’s much better to have a few larger categories than too many shallow categories.
By keeping the categories simple with unambiguous delineations, you can reduces the cognitive load for reporting issues and create broad deep categories instead of countless shallow categories. This helps get more value out of the groupings.
Distinctions without Differences
It’s often tempting to use categories for categories sake, but the best categories do more than just group issues. Categories should help play a key role in your team’s workflow by grouping issues in a way that helps the team get work done.
One of the most common ways for teams to organize issues is by separating bugs from enhancements. If this plays a role in workflow, then it can be helpful, but more often than not we see it used as a proxy for priority or managing scope. More often than not, the bug vs. feature approach is a distinction without a difference when it comes to workflow.
If used as a proxy for priority, it blurs the lines a bit. If it’s a matter of in-scope or out-of-scope, that’s best handled by using milestones or closing the issue with a resolution that it’s out of scope. If an item is in-scope, it can be assigned to a milestone. If it’s out of scope, it’s left without a milestone, and thus implicitly “unplanned.”
As with anything in life, these rules aren’t written in stone. They’re guidelines to help ensure your categories help your team get work done rather than slow them down making unnecessary decisions. It may seem trivial on the surface, but the more you can streamline your process, the better your results will be.