Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Top 7 problems in your Jira issues that seriously reduce your team’s effectiveness

Did you know that the name JIRA comes from Godzilla?

To be precise, it is derived from the Japanese word “Gojira” describing the mythical and strong ‘king of the monsters’. And to be honest, this couldn’t be more accurate. Jira, developed by the Australian company Atlassian and first released in 2002, is the real king among project management software solutions, extremely powerful and useful.

Jira is an essential tool for effective teamwork and building great products. It connects people and activities, helping them to plan, manage and report on their work.

Thanks to its high configurability and flexibility, it can be used across different environments and processes. One of Jira’s biggest advantages is the possibility to submit different kinds of requests while controlling and prioritizing workflow for the team.

When organizations and teams cooperate in Jira, they break down pieces of work into issues. Issues can refer to tasks, software bugs, feature requests or any other type of project work. Almost everything one wants to track can be an issue and these issues are all a project consists of.

Issues are the basic elements of any Jira project. They are divided into several key areas. The aim is to see all the critical information, such as an assignee, due date and description, all in one place.

Every issue undergoes a process called a workflow. These workflows define the steps of the process that an issue follows. Thanks to the fact that every issue can be tracked through the workflow, everyone is able to see its status and the steps that were taken during its way to completion. Jira enables constant communication during the work on the project while keeping the visibility of tasks’ status.

Jira seems to offer a complete solution for every team’s needs. However, it does sound too good to be true, doesn’t it? As everything in life comes with downsides, so does the collaboration in Jira. In this case the main disadvantage is simply called a human factor.

All of us working in Jira have been at least once assigned an issue with a highly mysterious title like “Some buttons don’t work”. It could have also happened that at some point we received an immediate request containing a single-phrase description “bug fixes” being our only hint about the changes to be made. This level of ambiguity is highly irritating and additionally can cost us too much time and money spent on looking for better explanations.

What does it mean in reality?

It means that all team members start to chase one another with tons of explanatory questions instead of simply getting down to work. As a result, disruption and distraction are sneaking into the process and making the completion of work too long and frustrating.

What we should remember is that the titles, descriptions, and messages provided by us during a Jira process are to make our colleagues’ work easier and, as a result, improve the quality of  teamwork and boost overall performance.

We listed for you the TOP 7 problems encountered in Jira issues that seriously reduce teamwork effectiveness. We are also giving you some clues on how to overcome them.

 

1. Ambiguous title

This is the most important part of the issue. It cannot be too general and bland as its main role is to get the assignee attention. A title should be a real call to action as it helps your colleagues who are browsing Jira dashboards.

You should know specifically what an issue is planned to resolve just by its title. In other words, the title should describe the action that the issue is to fulfill and as such, it can leave no room for assumptions.

If you are having trouble coming up with a specific enough title, consider breaking the ticket down into smaller subtasks, or promoting the ticket to an epic.

2. No description

If an issue has no description, an assignee may not know what this issue is about. A description is planned as a piece of detailed information about what should be made to meet the requirements.

It should identify the problem, point the environment where it occurs and describe its influence on the process. In case of a bug, it should also describe the problem from the user’s perspective. It is desirable to include the steps needed to reproduce the issue and describe what the expected result should be.

The description field should provide extra information about the goal of the issue. The description should be written as concisely and clearly as possible. It is a good idea to use Jira’s formatting tools, like bulleted points, to organize the information better.

Avoid writing large amounts of text in the issue description as all the excess text will make essential details harder to find.

On the other hand, describing the undesired aspect of your website with words “this looks bad” isn’t specific enough either. Keep the issue content focused on specific commands to help your colleagues understand how you’d like the issue to be changed.

The issues with no or too general description can be real project blockers. The point is to identify them soon enough so that they don’t hold up the entire team and slow down the process.

3. No status changes

A Jira workflow is the set of statuses and transitions that an issue undergoes during its lifecycle. If your team members don’t make status changes while working, then the team’s actual issue flow won’t be correctly indicated. And there won’t be any evidence that a Jira user is working on the particular item. Make sure everyone in your team is used to adjusting issue statuses when required.

Having made changes to the issue, remember to update the status to keep it moving forward. For instance, if one of your team members moves a ticket to “Review” and you realise that there are some problems that weren’t notified in the original description, change the status of the issue back to “In-Progress”.

By doing so, you communicate that there are changes that need to be introduced before the task is classified as “Done.”

4. Long time without update

The work on an issue should be delivered continuously. If some issues are latent for a specific amount of time, they may unnecessarily prolong the way to the project completion and cause misunderstandings among team members. Besides, the lack of any progress and update in a specific issue may suggest that it is blocked.

5. Wrong priority

An accurate perspective on the problem is the key!

Do not exaggerate and heat up the atmosphere. Try to use emergency priorities like blocker or critical sparingly so that your colleagues have a correct perspective on exactly what problem requires the most immediate attention. Having correct priorities set helps the team to focus on the most pressing issues first.

6. No attachments/ resources

Sometimes even the best description of a problem is not enough when it is not accompanied by a proper visual explanation. If any mockups and images are available, they should be attached within the issue. They really make a difference for everyone involved in the process!

All additional technical details such as specific URLs, browser version or device used, screenshots pointing out problems, short video clips / GIFs demonstrating steps to reproduce the bug or links to other tickets will give the assignee a better idea on how to address the issue.

7. No comments

The number of comments helps to determine which issues may need attention or are taking a lot of collaborative work to resolve. It is crucial for a project leader to be always on top of events in the project – in that way he/she may work towards removing all the obstacles slowing down the whole process. Moreover, if the issue needs to be reassigned to someone else, the new assignee will be able to find all of the crucial information and answers to some questions in one place. Lack of comments in Jira issues may suggest that most of the communication between the team is happening outside of Jira or via private channels, what's especially inconvenient for bigger teams.

 

This article has been prepared by the SolDevelo team, and is also available on our blog.

9 comments

I couldn't agree more!  As the administrator and champion of JIRA, these are the things that I struggle to impart on our users.  If everyone would just use JIRA and do their part - which takes very little effort - we would be humming along.

This is an amazing post. Simple things that have a big impact!

I think No.7 is super relevant, although I would add to it. Rather than no comments being an issue, I find misuse of comments being a bigger problem. People defining scope in comments as it evolves and not updating the description, meaning QA need to trawl through them trying to find out exactly what was decided being a key problem.

I totally agree with you @Daniel Simper - it's easy to hold the conversation about the desired outcome of the issue in the comments and then forget to go back to the description and update it to reflect on what has been decided. It's then a waste of everyone's time trying to figure out whether the version in the description or in the comments is the correct one.

It was kind of funny reading this article and having flashbacks of actual moments like this.

 

It all boils done to why the user actually uses Jira, imo:

If the user only uses it because he/she "should" - definitely you can expect these behaviors and more.

But the real "why" should be different :)

We try to avoid tickets being not updated for a long time by promoting ticket ownership in our service desk team.  The owner of a ticket will keep track of activities and is supposed to chase both reporters (for feedback) and support people (for progress) on regular intervals.  This, in combination with good escalation rules, makes us fix incidents within defined service levels.

To be more precise: Bugzilla > Godzilla > Gojira > Jira :)

Thanks for this, it was helpful for me!

A good read, thanks for this!

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you