JiraJira Anti-Patterns

A couple of weeks ago I was coaching a group of new Jira users. Any time I am working with people new to the tool I always like to provide context along with anti-patterns. If you are not familiar with the term anti-pattern it simply means a common approach to doing something that seems like a good idea, but in the long-run likely won’t work out very well. One of the people in the group said he was copiously writing down the details every time I mentioned one of the anti-patterns and asked if I could put a blog post together with all of them in one place. I said sure, so here it goes…

Most of the other anti-patterns won’t mean much if you are not on good terms with your Jira administrator(s) since they hold the keys to your Jira kingdom. Their lives can become miserable when every project wants to be customized to the nth degree. Work with them to strike a balance between tailoring to your needs and maintainability on their end

One of Jira’s strengths is that the entire team can easily contribute. It defeats the purpose of having a tool like Jira if everyone needs to push their updates to a single person just so they can update the issues. Your SM has far more valuable things they can be helping the team with than updating issues. Every team member should be responsible for updating their work in Jira.

It’s hard to trust information if you are concerned it may be stale. Being lazy about updates is a slippery slope. The staler it gets the less concerned everyone is about keeping their stuff up to date. Updating your issues takes no more than a minute or two. If everyone updates their issues at least once/day the team will be way ahead of the game.

Just because you can doesn’t mean you should. It is very tempting to try to map every detail of your process and force issues through every status. However, won’t take long for team to feel such a rigid workflow getting in their way and they will just stop using it. Keep your workflows as simple and flexible as possible. Prove to yourself you need something more advanced before you implement it.

Ideally every status in a workflow should have a doing and done state. This makes it easy to see if something is actively being worked on or waiting to be worked on. Jira doesn’t support this formally, but you can achieve the same thing by having status pairs like Ready for Development and In Development. This will also allow you to measure your flow efficiency since you can capture the total working time vs waiting time.

When issues remain in the backlog until work actually begins on them it makes it more difficult to see what work has actually been planned. You achieve that visibility to an extent with versions, epics, and sprints, but it can still be confusing. I always encourage teams and organizations to have a status in their workflows like In Planning. It is a very simple way to distinguish issues that have merely been captured, which is all a backlog item is, vs. issues we have made a conscious decision to implement. In addition it assists in expectation management with stakeholders and allows you to have a much more meaningful lead time measurement.

I have seen this quite a bit. Because Jira makes it easy to collect approvals in the workflow companies often go crazy and start adding approvals all over the place. Remember, approvals are a constraint and constraints are something we want to reduce and eliminate if possible. Only implement approvals where they are absolutely required such as in regulatory environments.

Another pattern I have found to be very common. Teams begin using Jira as a primary mode of communication with one another thinking they can eliminate meetings/ceremonies. Just don’t!!! Use Jira to prompt discussion and capture the outcomes and decisions made in those discussions, but don’t be fooled into thinking it is a replacement for face to face or online discussion.

Comments are a great feature, but they susceptible to the same pitfalls as we have all seen with email and chat tools. People have discussions and make decisions in a chat thread, but don’t bother to put that information into the issue’s description or wherever the story details and acceptance criteria are stored. You should not need to scan an issue’s comment history in order to understand what needs to be done.

The constant bombardment of email notifications from Jira seems to be a universal pet peeve with just about every Jira user I have met. The default Jira notification scheme notifies the Reporter, Watchers, and current Assignees of just about any kind of update to an issue in real-time. It quickly becomes noise and defeats the purpose of notifications in the first place. Cut down on the events that send notifications to just those that are of real value and only to those who really need them. This is one area where customization on project by project basis is worth the time.

I see this all the time. Team use versions, epics, and/or sprints to categorize work. For example let’s say a team has the following three epics:

• DevOps
• Support
• Tech Debt

The above are examples of categories of work rather than something that will deliver specific value. An epic is supposed to represent a deliverable piece of value with a distinct set of acceptance criteria that define when it is complete. Additionally the examples above will go on indefinitely as issues will be continually added to each of them. Teams will do the same things with versions and even sprints. Here is the problem with that approach. It convolutes your reporting and measurement and makes it very difficult for anyone not intimately familiar with your project be able to look at the information and understand what your working on and the progress you are making. Leave epics, versions, and sprints for what they were intended for and use components, labels, and linking to categorize your work.

Another case of just because you can does not mean you should. Jira allows you to estimate and capture actual time spent all the way down to the subtask level. For some teams this may provide value, but more often than not it just becomes a lot of overhead and is not terribly accurate on either end of the equation. It might even be a good idea to turn off the time tracking just to prevent temptation.

This ends up being a lot of wasted time especially if you are new to Jira. The configuration options in Jira are extensive and very difficult to anticipate completely ahead of time. Start off with the bare essentials and determine how you need to evolve your configurations based on real world experience and feedback. Jira is easy to change so there is no need to figure it all out up front.

Jira is a great tool, but it won’t make up for flawed processes, structures, or cultures. A very common pattern is for companies to purchase Jira, get their employees training on how to use it and then think they are off to the races with Agile. That is a sure fire recipe for a failed Agile implementation. At best Jira may help expose some of those underlying issues, but it won’t correct them.

If you want your teams to completely game the data, grow to hate Jira, and make any information coming from it mostly useless then by all means go that route. Otherwise, don’t even think about using it in that kind of dysfunctional manner. The more teams see Jira as a tool to help them the more it will they will leverage it to improve. The more they see it as a tool to police and judge them the more they will fight it.

Jira has thousands of plug-ins and they always sound like the greatest thing since cable TV, but unfortunately it doesn’t always work out that way. Try the plug-in out in a staging environment first and then with selected teams in production to evaluate its actual utility and the potential negative impact it may have. Plug-ins can sometimes conflict with one another and they can also have a noticeable effect on the user experience.

It never ceases to amaze me how pervasive the idea is that you should never delete anything from your backlog because you might need it one day. There is also the notion that it sends a negative message to the stakeholders who made the request. First, backlogs quickly become an unwieldy mess which really defeats the whole purpose of having an ordered backlog. I did a study once with a company I was working with where I examined the backlogs of 25 of their teams. What we found was that for pretty much every team a story had just a mid single digit probability of being implemented after only 3 months. In other words any story 3 months old or more had next to no chance of being done. Second, closing issues that have very little chance of being done helps manage stakeholder expectations. Better to tell someone their request won’t be done than having them hold out hope indefinitely. Keep those backlogs clean and concise by closing old stories. If you end up needing something you closed it is still available in Jira, but it won’t be clogging up your backlog in the meantime.

I mentioned you can go crazy with customization, but the opposite problem can be just as bad. Different teams and groups have different needs. Don’t assume what works well for one group will work well for another. You may gain efficiency in terms of maintaining and managing Jira, but in doing so may gum up the works for your teams. It’s always going to be a balancing act between the two. Jira teams and admins need to work closely together to determine what works best on the whole.

I have felt this pain first hand and I don’t wish it on anyone. The people who are leading the Jira implementation and management should be dog-fooding it every step of the way. No excuse not to.

So, there you have it. This is by no means an exhaustive list and like anything else your mileage may vary. I would suggest using the list as things to be aware of and think through rather than a list of absolutes. I would love to hear of other anti-patterns you have come across in your Jira experience and how you have learned from them. As always feedback is always welcome and encouraged.