Jira Software is part of a family of products designed to help teams of all types manage work. Originally, Jira was designed as a bug and issue tracker for teams to better track these items together. Today, Jira has evolved into a powerful work management tool for all kinds of use cases, allowing teams to track, plan, and work more efficiently. From requirements to test case management, Jira can help streamline many parts of a project from one centralized location.
Work becomes a lot more visible when it’s all in one place. It makes collaboration a whole lot easier.
-JEFF LAI, INTERNAL INFRASTRUCTURE, CANVA
I have been using JIRA since I started my career and as much as it helps as a tool for project managers, it also helps in keeping the team on the same page. Jira might seem overwhelming at first, but once you get comfortable with it, it becomes a great resource for efficient work. Jira can help reduce a lot of calls required to communicate on the project and also makes it easier to backtrack and analyze issues.
No one likes to be on multiple calls a day answering questions over and over again, so what if there were some practices we could follow that could replace those calls, answer those questions, and help make work easier? In this blog I will share 10 of the best practices for developers using Jira that will benefit all the team members.
Utilize Workflows: Workflows in Jira allow for team members to see where progress stands on the board and helps them understand what’s on their plate while allowing them to see the status of everyone else’s workload. Workflows allow for the team to have full visibility into what’s being worked on, what can be worked on, and what state each work item is in. But will that happen if we are not moving tickets into the right status?
Sometimes the team can be in a hurry or eager to debug an issue and forget to assign the ticket or move it to an “in progress” state, which could cause confusion for the team and result in multiple developers picking up the same issue, resulting in the loss of productivity and hours. It's important to follow workflows and make sure you are moving tickets into the right status as you work on them so that the whole team can remain aligned and progress can continue.
- Address ambiguity on tickets: When picking up a new ticket, it is normal to have some questions, concerns, or doubts about the ticket details. More often than not, we discuss those concerns during standup calls with the team. However, a discussion over a call is difficult to track unless it is documented somewhere. The right way to discuss any ambiguity on a ticket would be one of the following:
- Ask questions on the ticket itself so that it will be easy to track the changes in the future. Be sure to be descriptive, utilize tagging, and link any necessary documentation or images.
- Mention the discussion from the call in the ticket comments to track it better. If the question gets answered during a standup call, it is important to track that discussion in the ticket for visibility and understanding. This way, other team members and project managers can have visibility into the discussion and be aware of any changes to the approach or implementation. Be sure to also update any implementation or requirement changes in the ticket description as well.
- Tracking progress: For tasks that take a long time to complete, there should be a way to track the progress made on the work item by the end of each day. This will help with the following issues:
- If the developer has to take leave for any reason, another developer could continue on the task where the previous developer left off without having to restart the work on it.
- Allows for leads or Technical Architects to review the code better, as it is easier to review chunks of code instead of reviewing a set of files with a lot of changes.
- Reviewing in the early stage will also help in cases where a change in implementation is needed, as it will be easier to adjust in the beginning stage rather than completely rework the task once it is further along.
A solution to address these would be to add the link to the work-in-progress updated code by the end of the day and leave detailed comments on the work that was completed.
- Prioritization: Every issue in the JIRA management system has a priority level to determine what issues (tasks) should be picked up in order of criticality. In case you have multiple tickets of high or equal priority, it is important to get confirmation from your project lead on what to pick first rather than making assumptions.
- Tip: Tasks that will take more time to test or tasks that will have a lot of code changes should be picked first. This would provide leads with enough time to review and you with enough time to address feedback and complete the task on time. Be sure to discuss this approach with your manager to determine if it is right for your team.
- Tip: Tasks that will take more time to test or tasks that will have a lot of code changes should be picked first. This would provide leads with enough time to review and you with enough time to address feedback and complete the task on time. Be sure to discuss this approach with your manager to determine if it is right for your team.
- Comments for communication: Comments help create a source of truth for everything being done on the project. Project communication through Jira comments keeps every team member on board with what is being done. Consider the following scenarios and how comments could help resolve these issues:
- Consider a scenario where a bug ticket was created and after debugging we learned that the resolution does not require any code change. We discussed the bug on a call, applied the non-code solution (could be something as simple as clearing the cache or updating content), and closed the ticket without leaving a comment on the ticket. A few months later, a similar bug was raised. The obvious approach would be to review the previous bug to understand how we fixed it earlier. Since the bug was discussed on the call and the ticket closed, there is nothing we can reference and we now need to debug the issue all over again. A simple solution to address this would be that every time we close a ticket that does not require any code changes, we update the ticket with the investigation and solution applied so that we can document and track our changes.
- There are times when a task gets discussed on other communication channels such as Slack or Teams, which makes it very difficult to track that conversation in the future. The right thing to do when a work item is discussed via a communication channel is to update the ticket with a summary of the discussion and any updates or changes decided for the work item.
- Backtracking issues only works as long as there is information to track. Along with the tasks and discussions, it is important to track the code as well. Code updates must be referenced or linked to within the tickets so that a team member is able to reference the code where the change was made. This way, any issues can be easily and directly addressed. Think of a situation where a bug was introduced and the team is trying to resolve the issue. If the code is referenced in the ticket, the issue can be more easily found and resolved.
- Web linking: Utilize “web link” to add external reference links or even code links (pull-requests) directly into the ticket so that team members don’t have to look through comments to find them. This will save time for everyone involved, as references will be readily and easily available.
- Thorough Description: Ticket descriptions can contain acceptance criteria, implementation details, and even testing steps.. Make sure to update the task description to reflect any changes discussed or agreed upon in other communication channels. A thorough ticket description should be a source of truth for the work item. Every attribute in the description should match with what has been implemented and what needs to be tested to achieve the task.
- Testing steps: Sometimes testing steps need to be updated by either leads or developers, especially when testing requires some technical background. In such cases, adding testing steps before handing it over for testing helps reduce back and forth movement of the task and hence saves time as well. Be sure to be thorough and descriptive in your testing steps so that the team member handling Quality Assurance testing can understand and follow the steps.
- Developer testing: Developer testing helps uncover any misses or issues in our work in advance and allows us to fix them before it moves to the tester, rather than waiting for the tester’s feedback. This helps save the tester's time and reduces reopens, as issues are addressed before they move to Quality Assurance testing.
- Tip: Add screenshots of the resolutions supported on your work for visual testing. If the same task gets reopened by the tester, we can compare the screenshots and quickly identify if it is something we missed or a regression.
- Tip: Add screenshots of the resolutions supported on your work for visual testing. If the same task gets reopened by the tester, we can compare the screenshots and quickly identify if it is something we missed or a regression.
- Define impact areas: As developers, we are the better judge to identify impact areas of the task based on the changes made in the code. At times, changes made on a particular component can impact other components, especially when we reuse code for multiple components. Adding details for impact areas for regression testing helps with saving time, fewer reopens, and successful delivery.
I hope these tips were helpful to all who have recently started working with Jira and a good reminder for those who have been working with it for some time. Let’s continue to learn together and grow together and use our tools to benefit us.