Clean up your issue tracker by using only the most essential attributes for your team.
Are you lost in using Jira issue attributes effectively? Do you feel that set up guidelines are not obeyed by the team at all, because teammates have a different understanding of what each attribute really means?
When many available attributes are mandated, the team will be overwhelmed, and using attributes is only perceived as bureaucracy without purpose.
I worked with Jira for many years and faced exactly this issue. But it's not only about Jira; all issue tracking tools provide a bunch of attributes which can be set on an issue.
This article tries to simplify things and gives some useful hints. It collects available attributes and briefly discusses their purpose (or what I think the purpose should be).
In the Jira world, the term "field" is used. But I prefer to use the more generic term "attributes".
But before that, we must be on the same page about what an "Issue" really means. Here is my understanding:
"An issue is a discrete unit of work that tracks a specific task, bug, or requirement from inception to completion. It serves as a centralized record containing essential details like priority, assignee, and status to ensure team alignment. Ultimately, issues function as the fundamental building blocks for collaboration in an agile team, allowing for better balance of work and guaranteeing an optimal flow for the team."
Attributes Discussion
Project
Projects group issues into separate domains, areas of responsibility, teams, or projects. Each issue belongs to exactly one project. This separation is useful, because it provides the opportunity to maintain virtually separated issue tracking systems without setting up different tool instances.
Issue Type
Issues can be of different types. The most used ones are: Story, Bug, Task. Then I could imagine types like RCA (Root Cause Analysis), Question, or Investigation. It only makes sense to distinguish issue types when you want to set up and use individual workflows, user dialogues or input forms depending on the type. Otherwise it's just another piece of information which is mostly unused. If you don't need different workflows, use a Label (see below).
Component
Components are technical parts of your system (hardware, software, services) which are affected by an issue. In theory, it allows the team to see what current issues (changes, bugs, deployments, features...) have a potential influence on which components of your software system. This sounds practical and relevant. But it requires a good component definition concept, strict discipline from the team to assign components and a good view from the components perspective. I have never seen a team really applying it effectively.
Label
This is the most flexible and practical way to tag an issue for classification, documentation and filtering. When carefully set up, this is a very effective tool. It's crucial to decide what labels are used for and in what dimension they shall classify work. Labels could be used to introduce classification between:
- issue types (bug, task, story)
- releases/versions (v1.0, v1.1)
- components (server, os, app, cloud)
- scope (ui, feature, security, refactor, performance, doc, marketing)
You see that labels can even be used to replace other attributes. But you should generally decide what labels are used for and what they shall classify or structure. It's not a good idea to use them to classify different dimensions which are too varied like releases and scope or issues type and scope. This would end up in weird labels like ui-v1.0 or ui-bug). I would recommend to use labels to classify the scope and use different attributes like issue types (if really required) or releases (see below).
Priority
In my personal experience, this is the most overrated attribute. I have seen complex priority structures up to 5 different levels. Some process owners may hope that the more priority levels we have the better the process will be. The opposite is true. Maybe in ITSM it makes sense to classify customer tickets into 2-3 urgency or impact levels to derive workflows or measure against SLAs. But in software development we should use tools like Kanban boards which already allow to prioritize issues by ordering them within one column or by assigning to different columns. Here, we don't need extra complexity by imposing different priority levels, which are mostly ignored. What we actually need is the distinction between normal and prioritized issues. This means, we only need "normal" and "high" priority, complemented with a colored visualization on the board.
Release
Releases let you group issues into named, time-boxed deliveries and track their progress. This is a great idea. Even, if you practice Continuous Delivery, it makes sense to bundle issues for planning and marketing purposes. I like releases. When effectively used, they help so much organizing the team, tracking progress, revealing plan deviations. Releases bridge the gap between short-term agile work and long-term milestones for a product.
Epic
In agile software development, an Epic is a large unit of work that is too extensive to be completed in a single sprint or a short period of time. It's like a bracket that groups together several related tasks.
This sounds similar to the Release definition, Epics group issues too. So, what do we need Epics for when we already have releases (and projects, labels...). I know that the agile coaches will contradict. One could argue that releases group issues towards a time goal (milestone) and Epics group issues by a topic. But in my experience, this distinction is too complicated to apply. It only results in inconsistent usage of both attributes. Finally no one really knows when to use an Epic or a Release for a specific purpose. I have seen teams assigning Releases and Epics to issues with the same string, because they couldn't decide.
Subtasks
This is actually not an attribute of an issue. But it's related and I would like to take the opportunity to share my opinion here.
Subtasks as implemented in Jira are another opportunity for overcomplicating things without added value. Subtasks are well shown in the issue details but their tracking in a board is a challenge. The root cause is that Jira treats subtasks as an issue having its own card, id, lifecycle. When you heavily use subtask, your board will be flooded with subtask cards and the relation between subtasks and actual issues is not well presented on a Jira board.
So, I would not recommend using subtasks like in Jira. I think, subtasks should belong in a fixed manner to an issue and are just a checklist of things to do within one issue. This helps to break issues down into smaller, checkable items.
Conclusion
I am a big fan of the KISS principle ("Keep it simple, stupid") and pragmatic but effective solutions. So, I would recommend agile teams to use only these attributes:
- Projects to separate totally different topics
- Labels to classify per scope (feature, infra, bug, ui, perf, refactor...)
- Priority to only highlight urgent issue
- Releases to group issues for deliveries and track their progress
- Subtasks as a kind of check list, integrated in one issue
This is straightforward, effective, and understandable for the team. So, there is a good chance that it will be applied and provide real benefit to the team. Of course, we also should have an Assignee per issue, but this is another story.
References
If you want to see an example, then check out my own lightweight issue tracking and planning application wuFlow. Here I applied this scheme.
And if you are interested in Jira alternatives, read my review of self-hosted alternatives for modern teams.
Top comments (0)