This is a guest post by Dee Ann Pizzica.
So you’re on an agile software development team and your company chose Jira as its tool for tracking work. It’s a great tool. It’s highly customizable. It works well enough. But everyone seems to just tolerate it; no one seems to like it.
Anyone who has worked on a team using Jira has probably heard some complaints, and maybe even declarations of hatred. Your QA staff might be the exception, and that may only be because they’re used to it.
How do you quiet the complaints of the haters and improve your team’s experience with this tool?
Before we dig into the details, there are a couple of important ideas to keep in mind as you read.
Remember that Jira is a tool to help you achieve your goals and to support your process. It is not your process itself (agile or otherwise). Jira can bolster any process you choose to follow, but ultimately it is just a tool. No tool can magically solve all your team’s problems.
The other big idea to keep in mind is that teams need information that is actionable, not interesting. When setting up your environment, challenge yourself. Ask why you want any piece of information. For example, tracking the number of bugs logged in a sprint is possible in Jira. The number of bugs logged may be interesting to know, but does that knowledge inform decisions about your process? Will having this data promote positive changes?
There are all kinds of interesting work items that will get logged to help you observe trends. Resist getting bogged down in data you can’t act on. Go ahead and log everything in Jira so it’s in a central location, but avoid making anything too precious, because you haven’t got time for that.
For clarity, in this article I refer to anything logged in Jira as “work items,” “issues” or “tickets.” There are a bunch of standard categories you might use, such as epics, user stories, bugs, tasks and subtasks. All can have rules, restrictions and different fields. It can get complicated. But at its core, anything you put in the tool is something you or someone else is going to work on. If you want someone to do work, it should be clear, compelling, approachable and searchable. If you can achieve that, you increase the likelihood that the work will get done. And getting work done is the goal, right?
That being said, here are some of the biggest complaints teams have about Jira and what you can do to address them.
“I can’t find anything in Jira!”
Every bug and every great idea your team has is logged somewhere in Jira, but no one knows how to find them. It’s a legitimate complaint. Between sprint boards, backlogs, projects and epics, there are a bunch of places work items can hide. However, there are some solutions.
Finding work items in Jira starts outside of Jira
Step 1: Establish common terms and language.
The team needs to agree on the words they’ll use to describe the work you do. If you call the new feature the “onboarding widget” and I call it the “new user flow,” both may be accurate. However, using different terms is inefficient and our team is likely to get confused. A common language provides clarity throughout the project and will improve communication.
Step 2: Pick out keywords for projects and features.
You need terms that are searchable. “Onboarding” is going to be more concise of a term to look for later, whereas “flow” might get used in several places.
Step 3: Use your keywords in the titles of your work items.
Try to begin the name of every item you log with a key term that is universally understood by the team. This term will indicate specific features or areas of the code. This allows you to search and sort based on a set of terms that are meaningful for the team.
Keep in mind that others on your team need to access information without your help. If you use language that is only meaningful to you, then no one else can search effectively, and your work may be lost. Work that should be grouped together might get missed when someone else searches for it. You become a bottleneck because you’re the only one who can ever find anything.
Now that you’ve established a set of meaningful terms and categories for all the work you do, label everything. You can use as many labels as you want on a ticket. Once you have some stored, they show up as you start typing so it’s easy to reuse them.
These labels can be product-related or engineering-focused. On my team, any given ticket might have the labels “buy flow,” “fees,” “order history” or “customer reported.” These may seem generic, but each term has meaning to the team and points to specific pages, functionality and visibility.
Once you label everything, you can build better queries. You can search for all “buy flow” tickets, and then you can add “customer reported” to that list.
I keep a spreadsheet of labels that anyone on the team can access with a translation of what any term means. Everyone contributes so that we agree on the same language to describe our work. This kind of documentation can seem unwieldy, especially for new team members. Add a reminder to your onboarding checklist to walk through how the team uses Jira and where to find the common terms that everyone uses.
“The backlog is a mess!”
It’s easy to create a chaotic pile of tickets that turns into a seemingly never-ending backlog of issues. It becomes difficult to get anything done, and at that point, the system starts to break down. The answer is to implement a prescribed process to filter, sort and focus your backlog items.
Epics are great for organizing. You can set the epic tag to show up in the backlog, which helps you to quickly identify items that belong together. No team ever plans to end up with hundreds of items in the project backlog, yet this inevitably happens. When you create epics, you help your teammates spot any tickets that might be evaluated together.
Another helpful feature of an epic is that all the linked issues display in a big list. You can easily scan through that list and see the status of everything. You can also add a description that explains the goals and purpose of that group of tickets.
Sprints are really just another way to filter work and provide focus for the team. Assigning work to a sprint also triggers “agile mode” in Jira. You can view those tickets on a sprint board with custom columns, and suddenly progress becomes obvious. If you’re working on an agile team and using Jira, likely this is the main view your team uses.
But here’s something you may not have tried. Create sprints not just for a regular sprint, but because you need to track some group of tickets together regardless of the time frame. For example, your customer support team keeps tickets for updates related to open customer reported issues. Scattering those tickets throughout the backlog may make it hard to find and prioritize them among all the current new feature work. Create a sprint for them so they all stay together. You can always assign these to new sprints during grooming, when the team is going to commit to fixes.
Here’s a side hint for all those people who can’t find anything in Jira (including the sprint board): If your team has a dedicated Slack channel for the current project, try setting the channel topic as the link to the Jira sprint board.
“I can’t change that field!”
One of the hardest decisions an administrator has about setting up a tool for a team is what powers you grant to each user. Jira allows granular options for permissions and access. You can trust widely and keep everything as open as possible, or you can restrict everything down to just the permissions someone needs for their role.
I understand why having access to too much could be distracting and potentially dangerous. However, when working on collaborative teams, we need to train and trust. It is frustrating to learn that Jira administrators can do all kinds of things that make their jobs easier, and you can’t.
Admins should leave certain options open for their team and take advantage of some Jira abilities to make things easier.
Bulk updating is a powerful feature that some teams restrict. You might be tempted to restrict this because someone updated a bunch of tickets incorrectly, or you might feel strongly that developers and testers should be adding comments to provide some information every time they interact with a ticket. But even the most detailed teams need shortcuts sometimes.
Status is a common update that everyone on the team needs to update. Perhaps it’s a bunch of tickets that are deployed to a staging environment and ready to test. It may be that you want to split apart an existing epic or add a new label to several tickets. Whatever the reason, teams need to be able to move quickly. The more administrative work you require, the more people will blame the tool.
Everyone on the team needs to be able to move issues. In Jira, this means changing the project designation or the issue type. Each project and issue type can have different workflows and features, so you need to offer your team the flexibility to change any logged issue to best fit the work required.
A common example is a subtask created in a user story. Once the developer digs into a subtask, they learn more about the work. Sometimes what looked like a simple task turns out to be more complex than originally expected. In cases like this, it may make sense to break out this task into its own story instead.
If you want your team to track their work and close out stories at the end of the sprint, then you have to allow them to easily modify tickets. When the answer to a problem is to copy and paste a bunch of information, often that means that work doesn’t get tracked.
The status of an issue in Jira can be incredibly valuable in understanding what work has been done and what work needs to come next.
Create a basic workflow that utilizes common statuses, like To Do, In Progress, Code Review, Testing, Ready for Deploy, Done. Depending on your environment, these may vary, but most tickets move through these different stages in a predictable way. Ideally, the tool is smart enough to suggest the next step in the flow for you.
Problems arise when you want to do anything that doesn’t nicely adhere to the desired flow. This happens in all kinds of ways. You may have a developer who falls behind on updating tickets. The ticket stays in the To Do status even though it’s already been completed and it’s in code review. If you require that the ticket move through each step, you just have more administrative overhead to keep things up to date.
Forcing someone to adhere to a specific flow doesn’t fix process and communication problems. Ask yourself, is it more important that the work is complete or if the board is up to date? If the team agrees that proper status on the board is vital, then discuss why.
Sometimes the work changes after you get started. Steps you imagined would be necessary end up to not be required to complete the work. What you thought might need three separate user stories gets done in one, and now you’re moving three tickets forward for one ticket’s progress.
You can set up Jira to suggest the next step, but allow the user to pick any status for the times you just need to skip a step or two.
Provide a template of suggested information or create custom fields to capture all the data you want. Ask for everything that is important to you, but don’t require anything beyond the most basic pieces. Some basic fields you require might be project, issue type, title, and description. That isn’t enough information in most cases, but it is enough to get started.
Often, team members are logging notes about an issue they discovered while they were in the middle of something else. Make it easy for someone to record their thoughts quickly and come back when they have more time. Besides, not every work item that gets logged will require every field that you could possibly want.
You may be tempted to require specific fields or specific parts of the workflow in order to address process or staff problems. If you have a staff member who regularly doesn’t report enough information in the items that they log, that’s not going to change just because you add additional fields or provide a template. It is far more compelling to explain to that employee why you need that information and how it helps the team than to force them into a workflow that will require it.
The tool isn’t going to make your team communicate better. You can require your developers to provide root-cause information for bug fixes. Your quality team needs that in order to test that bugs are fixed. But the tool can’t force the developer to enter high-quality information. The tool may make it clear how much work is still in progress, but it doesn’t actually tell you what is blocking the progress from continuing.
Ultimately, the tool is there to enhance team communication. Jira is not a replacement for standups, questions, discussions and constructive feedback.
Nothing is sacred
Be willing to change. Be willing to delete and let go. The longer anything sits in Jira, the less likely it’s going to remain relevant. You need to be open to moving things around.
There is no way that the team will ever have time to fix everything that is in the backlog. Sometimes you have to let it go. If you don’t want to delete, you can just close tickets. Be realistic about what aligns to your team’s goals, because you can’t do everything. Only keep what your team plans to act on, and let go of anything that is only interesting.
“Why do I have to post the same information in so many places?”
If you’re regularly using tools that have integrations with Jira, explore those. Integrations help you to connect information from various systems you use so you don’t need to update everything everywhere. Here are a few tools your team may be using alongside Jira.
Slack has a nice Jira integration. You can set certain projects to update in different project channels. This way, when anyone types a ticket number, its corresponding link to Jira follows. This makes it easy to collaborate with others on any given ticket so team members can find and follow up on any issue that makes it into a Slack discussion.
There are also integrations with GitLab. Look for some integration with your code repositories. This way, if a developer mentions a Jira issue in a commit, links will post automatically in the ticket. At the very least this shows that work has been done on an item. In the best case, the corresponding link will provide additional context about the changes.
If your customer service team uses Zendesk to track support issues, you can also set up a Jira integration. Some customer-reported issues prompt a change from the development team. You can link any Zendesk tickets to a related Jira item. This allows the engineering team to more accurately determine impact based on how many tickets are linked. It also empowers the support team to follow the links and review the comments and status of the Jira ticket in order to observe progress that has been made toward a fix.
TestRail has a Jira integration too. This integration allows you to create bug reports from your test results. You can also link to Jira reports that are relevant to your tests.
Developing software relies on several tools. We should link and cross-reference in order to make information as easy to find as possible.
Communicate Clearly and Empower Everyone
Our goal for Jira is to have actionable information that enables us to get work done.
Work with your team to develop a common language, and then use that for everything that you log in Jira. You can use those terms to create more powerful searches. Group the work in any way that makes sense for the team. Allow your team to change the way the work is tracked. And integrate with your other tools as much as possible to minimize rework.
These suggestions can quiet the complaints about Jira as a tool, help track information better, and provide the team with useful tips for sharing important information that needs to be shared. Like all bits of information, you want to make sure you spend your time on what is most valuable.
Always remember to ask yourself: Is it merely interesting, or is it actionable? Let go of what you no longer need. And don’t force a tool into the job of fixing your process.
Dee Ann is a passionate and curious software tester. She has over 15 years experience in support of small and enterprise-scale custom mobile and web applications with highly complex business logic for clients across a wide variety of industries. Dee Ann is currently working as the Director of Engineering at BRD where she collaborates with a talented team on a cryptocurrency wallet app for iOS & Android.