If you ask people to come up with popular attributes for “Agile” or “agility,” Scrum and Jira will likely be among the top ten featured. Moreover, in any discussion about the topic, someone will mention that using Scrum running on top of Jira does not make an organization agile. However, more importantly, this notion is often only a tiny step from identifying Jira as a potential impediment to outright vilifying it. So in March 2023, I embarked on a non-representative research exercise to learn how organizations misuse Jira from a team perspective as I wanted to understand Jira anti-patterns.
Read on and learn more about how a project management tool that is reasonably usable when you use it out of the box without any modifications turns into a bureaucratic nightmare, what the reasons for this might be, and what we can do about it.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 46,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
📖 Get notified when the Scrum Anti-Patterns Guide book is available!
Join your peers on May 4, 2023: HoA EXTRA: How Elon Musk Would Run YOUR Business with Joe Justice.
Organizations might use Jira in restrictive ways for various reasons, although these reasons rarely align with the agile mindset. Some reasons include the following:
While these reasons might explain why organizations use Jira in restrictive ways, curtailing the agile mindset and a Scrum team’s autonomy or self-management will have negative consequences. For example, restrictive practices can:
Contrary to this, agile practices promote flexibility, autonomy, and continuous improvement, which organizations will undermine when imposing excessive control, for example, by mandating the use of Jira in a particular way.
Cannot see the form? Please click here.
I did not run a representative survey to gather qualitative data for this article. Instead, I addressed the issue in a LinkedIn post on March 16, 2023, that received almost 100 comments.
Also, I ran a short, non-representative survey on Google Forms for about two weeks, which resulted in 21 contributions, using the following prompt:
“Jira has always been a divisive issue, particularly if you have to use Jira due to company policy. In my experience, Jira out-of-the-box without any modification or customization is a proper tool. If everyone can do anything, Jira is okay despite its origin as a ticket accounting app. The problems appear once you start submitting Jira to customization. When roles are assigned and become subject to permissions. Then, everything starts going south. I want to aggregate these Jira anti-patterns and make them available to provide teams with a data-backed starting point for a fruitful discussion. Then, they could improve their use of the ticketing tool. Or abandon it for a better choice?”
Finally, I aggregated the answers to identify the most prevailing Jira anti-patterns among those who participated in the LinkedIn thread or the survey.
When I aggregated the effects of a mandated rigid Jira regime, they fall into four main categories:
The most critical Jira anti-patterns mentioned by the participants are as follows:
There were some memorable quotes from the participants of the survey; all participants agree to a publication:
- Jira is a great mirror of the whole organization itself. It is a great tool (like many others) when given to teams, and it is a nightmare full of obstacles if given to old-fashioned management as an additional means of controlling and putting pressure on the team.
- The biggest but most generalized one is the attempt to standardize Jira across an org and force teams to adhere to processes that make management’s life easier (but the teams’ life more difficult). It usually results in the team serving Jira rather than Jira serving the team and prevents the team from finding a way of working or using the tool to serve their individual needs. This manifests in several ways: forcing teams to use Company Managed Projects (over team Managed ones), mandating specific transitions or workflows, requiring fields across the org, etc.
- Stripping project admins of rights, forcing every change to a field to be done by someone at a different timezone.
- The biggest anti-patterns I have seen in Jira involve over-complicating things for the sake of having workflows currently match how organizations currently (dys)function vs. organizations challenging themselves to simplify their processes.
- The other biggest anti-pattern is using Jira as a “communication” device. People add notes, tag each other, etc., instead of having actual conversations with one another. Entering notes on a ticket to create a log of what work was completed, decisions made, etc., is incredibly appropriate but the documentation of these items should be used to memorialize information from conversations. I can trace so many problems back to people saying things like, “Everyone should know what to do; I put a note on the Jira ticket.”
- Breaking stories up into individual tasks and sub-tasks destroys the idea of the team moving the ball down the court to the basket together.
- Developer: “Hey, I’ve wanted to ask you some questions about the PBI I’m working on.” Stakeholder: “I’ve already written everything in the task in Jira.”
- Another anti-pattern is people avoiding Jira and coming directly to the team with requests, which makes the request “covert” or “Black Ops” work. Jira is seen as “overhead” or “paperwork.” If you think “paperwork” is a waste of time, just skip the “paperwork” the next time you go to the bathroom! 😬 🤢
- Implementing the tool without any Data Management policies in place, turning into hundreds of fields of all types (drop-down, free text, etc.). As an example, there are 40 different priority options alone. Make sure to have a Business Analyst create some data policies BEFORE implementing Jira.
- “A million fields”: having hundreds of custom fields in tickets, sometimes with similar names, some with required values. I have seen tickets of type “Task” with more than 300 custom fields.
- “Complex board filters with business rules”: backlog items are removed from boards based on weird logic, for example a checkbox “selected for refinement.”
When looking at the long list of Jira anti-patterns, the first thought that comes to mind is: What can we do to counter these Jira anti-patterns?
Principally, there are two categories of measures:
Here are some suggestion on what to do about Jira anti-pattern in your organization:
The following Jira anti-patterns counter measures at the organizational level require Scrum teams to join a common cause and work with middle managers and the leadership level:
Even if a Scrum team cannot customize Jira independently due to an organizational policy, there are some measures the team can embrace to minimize the impact of this impediment:
To use a metaphor, Jira reminds me of concrete: it depends on what you make out of it. Jira is reasonably usable when you use it out of the box without any modifications: no processes are customized, no rights and roles are established, and everyone can apply changes.
On the other hand, there might be good reasons for streamlining the application of Jira throughout an organization. However, I wonder if mandating a strict regime is the best option to accomplish this. Very often, this approach leads to the Jira anti-patterns mentioned above.
So, when discussing how to use Jira organization-wide, why not consider an approach similar to the Definition of Done? Define the minimum of standard Jira practices, get buy-in from the agile community to help promote this smallest common denominator, and leave the rest to the teams.
How are you using Jira in your organization? Please share your experience with us in the comments.
The Free Scrum Anti-Patterns Guide
ChatGPT 4: A Bargain for Scrum Practitioners?
Club Scrum: What Are You Doing all Day, ChatGPT — as a Scrum Master?
ChatGPT Prompts for Scrum Masters, Product Owners, and Developers
Learn more about avoiding Jira Anti-Patterns with our Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
Support your team’s efforts to avoid Jira anti-patterns by pointing to the free Scrum Anti-Patterns Guide:
TL; DR: System-Level Scrum Stakeholder Anti-Patterns Learn how outdated organizational structures manifest themselves in system-level…
TL; DR: Scrum Master Tasks: Let's Bust Some Myths! Rumor says that a great Scrum…
TL; DR: Scrum Master Interview Questions on Creating Value with Scrum If you are looking…