Article summary
Using the development tool Jira to manage software projects can be extremely useful, if you keep it in check. If you’ve spent any amount of time in Jira, I bet you’ve had at least one bad experience with it (or written it off entirely). Jira’s strength, its breadth of customizations and features, can also be its Achilles heel. Let’s take a look at a few common pitfalls in a typical Jira project and ways to avoid them.
Lack of Housekeeping
The number one issue I’ve run into (and am guilty of) is having a cluttered and overwhelming backlog. Nothing makes you want to slam your laptop close like popping open a backlog and seeing…
It’s horrifying. Jira makes it easy to create new tickets, but that has to be handled with responsibility. Too many times I’ve been in backlog grooming sessions or meetings with clients and have heard the phrase, “Let’s just quickly create a placeholder story for that.” Suddenly, before you know it, you have a back storeroom filled with things “I swear I’m going to organize at some point.”
As a scrum master/delivery lead/project manager the backlog is your baby. Keeping it tight and only filled with pertinent and groomed work will help everyone on the project. It makes it easier to scan for unpointed stories and related groupings that could be pulled into a release. This makes it less overwhelming for stakeholders and your product owner. In general, it also lowers the mental drain and drudgery of backlog grooming sessions. If you find yourself working with stakeholders who want to continue to drop “ideas” into the backlog, push back. Instead, explore other tools you can use to house and mature those ideas until they’re ready to become Jira stories.
Rigid Workflows
On the other end of the organization spectrum are rigid workflows. Years ago I worked as an IT project manager at a health insurance provider. They had a locally hosted, highly managed Jira instance. I remember the frustration of trying to transition a story from one status to another, only to be forced to jump through four transition statuses along the way. The last thing a tool should do is make you fight against it and slow you down.
You may disagree with me (excellent, let me know in the comments). But, I have a firm belief that process governance should be something that is upheld by people, conversations, and team buy-in, and not by administered rules and oversight that ultimately end up getting in the way. Instead, embrace the beauty of simplicity and build your workflow up as your project needs it. The most simple workflow might not be where you end up, but I would challenge you to start there and let your project naturally drive the need for additional complexity.
A few additional simple states + columns I’ve used in the past are: In QA, In UAT and Ready for Production.
Beware the Project Template
Of the three of these, this pitfall might be the least common, but it draws the most ire from me. On the surface, project templates seem like a great idea. You could make the case that they save time and create a process that removes the likelihood of missing something. Just go hit clone, and voila! You have a fully built-out project ready to go.
However, in reality there are a myriad of snares waiting to spring up along the way. King among these is losing the chance to establish a deeper first-hand understanding of the building blocks of your project. When you wholesale clone a Jira project, you’re wiping out all the micro-inflections you would have with your team while you write your stories from scratch. You become disconnected from the project before it even fully spins up and find yourself immediately wrangling a bunch of backlog heft instead of intentionally adding just the right amount.
There you have a few of my least favorite things to find in a Jira project. No doubt there are plenty more, and these are all just my opinion (man). What did I miss? What do you disagree with? I’m weirdly into well running Jira projects, but by no means have everything figured out and welcome any discourse in the comments.