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 work items. Work items can refer to tasks, software bugs, feature requests or any other type of project work. Almost everything one wants to track can be a work item and these work items are what a project consists of.
Work items 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 work item undergoes a process called a workflow. These workflows define the steps of the process that a work item follows. Thanks to the fact that every work item 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 a work item 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 annoying and additionally can cost us too much time and money spent on looking for better explanations.
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 the overall performance.
We listed for you the TOP 7 problems encountered in Jira work items 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 work item. It cannot be too general and bland as its main role is to get the assignee's 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 a work item is planned to resolve just by its title. In other words, the title should describe the action that the work item 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 a work item has no description, an assignee may not know what this work item 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 to 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 work item and describe what the expected result should be.
The description field should provide extra information about the goal of the work item. 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 work item description as all the excess text will make essential details harder to find. If the task is alarmingly extensive, consider using checklists to track the Definition of Done more effectively. Checklists are a wonderful way to tackle large work items without making them overwhelming. Sectioning the work into a list of smaller, digestible tasks that can be easily monitored and updated ensures that even extensive work items support your team efficiency, instead of undermining it.
On the other hand, describing the undesired aspect of your website with words “this looks bad” isn’t specific enough either. Keep the work item content focused on specific commands to help your colleagues understand how you’d like the problem to be fixed.
The work items 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 a work item undergoes during its lifecycle. If your team members don’t make status changes while working, then the team’s actual work item 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 work item statuses when required.
Having made changes to the work items, 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 work item 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 a work item should be delivered continuously. If some work items 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 work item may suggest that it is blocked.
Irregular work item updates are often coupled with inconsistent time tracking. These two problems stem from the same source. The lack of time. During a busy workday rarely is there time to chase down the work items you should update or log time into. They’re often scattered around different boards and not necessarily easy to find. It results in people leaving the troublesome task of updating work items for later, and sometimes forgetting to do that entirely.
Investing in solving this problem is a decision that can bring long-time benefits. Supporting your team’s time tracking habits with a tool designed specifically for this purpose can make the process much smoother and more effective.
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 the correct priorities set helps the team to focus on the most pressing work items first.
It is also important to engage the entire team in the planning process to make sure everyone is on the same page and avoid unpleasant surprises later on. Transparent and cooperative planning can work miracles in terms of accuracy, since the whole team has a chance to share their perspective on tasks, their estimations, and their priorities.
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 work item. 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 work item.
The number of comments helps to determine which work items 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 they may work towards removing all the obstacles that are slowing down the whole process. Moreover, if the work item 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 work items may suggest that most of the communication between the team is happening outside of Jira or via private channels, which is especially inconvenient for bigger teams.
Sebastian Brudziński
Head of Products
SolDevelo
Gdynia, Poland
15 accepted answers
9 comments