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.
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.
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.
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.”
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.
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.
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.
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.
Sebastian Brudziński
Head of Products
SolDevelo
Gdynia, Poland
15 accepted answers
9 comments