Is the Problem with Your Agile Tool, or How You’re Using It?
Tools can make our lives easier, especially when you start with a vision for what you want to do and then find or build the tool that helps you achieve that goal. A tool can provide a framework for how to set up a process, freeing you from thinking too hard about arbitrary decisions.
However, if you use the wrong tool, or use it in a way other than it’s designed, the tool can slow down your process. This seems like a particularly common problem with issue-tracking tools.
While using index cards and a wall can function just fine as a kanban or Scrum board, issue-tracking tools such as Jira can make it easier to manage a backlog, especially if you have a distributed team. But these tools are more complex to use and can add their own overhead to the process.
The Scrum Guide talks about product backlog items, which represent things that are needed for the product. Jira classifies by “issue types,” and this difference often leads to a lengthy conversation around which issue types to use and when. The discussion can be wasteful when these debates lead to unnecessary complexity. Teams forget the Extreme Programming principle of “the simplest thing that could possibly work.”
Simpler is better, but simple isn’t always obvious, as teams may have slightly different needs. Using one issue type sounds adequate and straightforward, but there may be business reasons for using more than one.
Regardless of how many issue types you deem necessary, remember that any work you do should have business value, be it a bug, infrastructure, or a feature. This implies that any item on the backlog should have essentially the same information: who will benefit, what is being asked for, and what the ideal result will be. These elements of the user story template—even if they are in a different format or just implied—can identify the criticality of the issue and outline the goal in a way to help you find the best solution.
With all these things in mind, the simplest approach to using a tool like Jira for Scrum consists of just two steps:
- Start with the default workflow, and resist customizing until you find a problem
- Use as few of the predefined issue types as possible
For example, you could start a new Jira Scrum project by designating Stories for everything. Or you could use Stories for new features and Bugs for issues found post-release. While I’ve rarely found a good use for Tasks, some teams use them to track work unrelated to delivery, such as onboarding and meetings. But whatever you decide, make sure that the definitions are clear, have a default meaning, and are understood by everyone.
Teams choose to adopt Scrum because it is a simple and adaptable framework that creates visibility. And teams use tools like Jira because they facilitate distributed work and feedback. But if Jira seems to get in your way, consider whether the issue is the tool or how you are using it.
