Jira is a great tool for Agile delivery. In the last ten years many organisations adopted it enthusiastically and its creators at Atlassian have become a big Australian technology success story. Looking to apply the benefits of agile across their business, organisations are adopting Jira for uses beyond just software development.
Because it is known as such a popular agile tool, organisations sometimes make it a core part of their processes figuring that more Jira = more agile. Ironically, they could be making their processes less efficient — not because of a flaw in Jira, but in how it is being used.
Signs your organisation should review how Jira is being used
1. Are Product Owners overwhelmed?
First, are the Product Owners fully across the content of their product backlogs? Or is the ‘noise’ in there making it difficult to keep track? Moving the noise content elsewhere will help keep the product backlog fresh, easy to comprehend, and easy to manage.
2. Have the terms “user story” and “epic” lost their meaning?
This is a very common one. Is the term “user story” now just agile-speak for “thing to do”? Is “epic” just an aggregation of these units of work? A good test is to go back to basics and think about what a user story really is: “As a <user type> I want <some goal> so that <some benefit>”.
Now if you look at the user stories in your product backlog, do they fit this format? Let’s look at some examples.
A real user story that belongs in the product backlog:
“As a subscriber, I want to update my profile email address so the newsletter goes to the correct inbox”
Not a user story:
“Get solution design approved”
Users don’t want to “get the solution design approved”. Yes this is important work that needs to be done, but users do not see it and it is not the “story” of any user. Regular steps like approving designs are better off in the Definition of Ready, because this needs to be done before the sprint starts. If someone needs to keep track of it, they use tools like MS Outlook or Teams. Putting something like this in the product backlog adds to the noise and adds to the burden of the poor product owner.
If every morsel of work in the organisation becomes a “user story”, everything will start to get fed into Jira. Jira however is not just a list of to-do tickets. It is also a series of customisable workflows. Items that don’t fit workflows will get stuck and are at risk of giving the false impression that somebody is addressing it. Your product backlog could end up becoming a black hole of pending work.
3. Can anyone can add anything to the product backlog?
Next, consider which roles can add new items to the product backlog. Is it a free-for-all or organised? I recently saw a company that integrated their Service Now help desk system with their Jira backlogs. The reasoning was that if a user found a bug, they would fill out a short form on the intranet site and it would automatically go onto the Jira backlog and eventually get fixed by a developer. In practice, this meant any user could add a new item to the Jira product backlog. Of course there are far more users than product owners, and multiple people would report the same bug, so the product owners were struggling to identify the duplicates amongst the avalanche.
Let the business analysts and product owners take the lead on drafting new user stories in the product backlog. For bugs, support staff, business analysts and product owners can triage and add proper backlog items where appropriate. This will help build strong lines of communication across delivery and operations teams, and the backlog will remain tidy and manageable.
Getting back on track
Jira is excellent for software development. Because it is so prevalent in agile teams, it is understandable that organisations figure that more Jira = more agility. Using it in the wrong ways unfortunately can quickly create confusion, inefficient bureaucracy, and can lead to a real drain on morale.
The clean-up starts with business analysts and product owners, judiciously creating product backlog items in Jira, and knowing what to move elsewhere. The benefit is that your teams will spend much less time on costly maintenance. Your Product Owners will have a much better grasp, and ownership, of their product backlogs. Then, the vision of where the product is going will be accurately refelcted in the product backlog in a way that is approachable, transparent, and easy to manage.
