Introduction
JIRA, a versatile project management tool, empowers teams to streamline work processes through effective workflows, boards, and priority levels. In this comprehensive guide, we’ll dive into the intricacies of JIRA’s workflow stages, board columns, and priority levels, equipping you with the knowledge to optimize your project management.
Remember that the workflow and the boards are subjective to each project, but we will exemplify what proved to be working quite nicely for us.
Understanding JIRA Workflow Stages
A well-defined workflow is crucial for tracking and managing tasks effectively. Here’s a breakdown of the typical workflow stages in JIRA:
-
- To Do: Represents tasks that haven’t been started yet.
-
- In Progress: Represents tasks that developers are actively working on. Once a developer starts working on a ticket, they move the ticket to “In Progress”. Note: Don’t start working on a ticket that isn’t in the current sprint unless the product owner instructs you to do so.
-
- Ready for Review: Represents tasks that are completed by the developer and are ready for QA testing. This stage can also be used for code review and preliminary testing, using the “Assignee” or “Labels” fields to differentiate each case.
-
- In QA: Indicates tasks being tested by Quality Assurance (QA) team members. Once the QA starts testing a ticket, the ticket will be moved from “In Review” to “In QA”.
-
- Done: Identifies tasks that have been completed, passed QA testing, and are ready for deployment.
Navigating JIRA Board Columns
JIRA boards provide visual representations of tasks’ progress. Here’s a breakdown of the standard columns you might encounter on a JIRA board:
-
- Triage: For all the newly created tickets that first need to be triaged to decide which will go in “Backlog” and which will go in “Selected for Development”.
-
- Backlog: Stores tasks, including User Stories, that haven’t been planned for development yet.
-
- Selected for Development/To Do/Work Next: Show user stories (US) and tasks planned for the current iteration.
-
- In Progress: Stores tasks that developers are actively working on.
-
- In Review: Contains tasks completed by developers and ready for review, either by the QA team or specific team members.
-
- In QA: Holds tasks that are being tested by the QA team.
-
- Ready to Release: Highlights tasks completed by devs, tested by QAs, and ready for deployment. The tickets validated by QAs should have a comment with the reason why it’s validated, along with a photo/video proof.
-
- Done: Highlights tasks that have been fixed and implemented. This column can also host the tickets that are deprecated/no longer valid – this kind of ticket must have a comment left by the PO/PM explaining why they are deprecated/no longer valid or not considered an issue.
For the “In QA” tickets, there are two possible scenarios:
-
- If the ticket is fixed properly, the QA validates the ticket using a comment and a photo/video proof, then moves the ticket forward into the “Ready to Release” column;
-
- If the ticket is not fixed properly, the QA will ping the dev leaving a comment and photo/video on what’s not fixed properly, and will move the ticket back into the “In Progress” column. The dev should start working again on the issues mentioned by the QA in the last comment and move the ticket into “In Review” once his work is done.
Understanding Priority Levels
JIRA provides a priority framework to help teams focus their efforts effectively. Here are the priority levels and their implications:
-
- Highest: a ticket with this priority implies that this problem is blocking progress and should be addressed as soon as possible.
-
- High: Represents a severe problem that could block progress. These issues should be addressed within the current sprint.
-
- Medium: Indicates an issue that has the potential to affect progress. It should be fixed after all the “highest” and “high” priority tickets are fixed – it can also wait until a new version is created/a new sprint starts.
-
- Low: Denotes a minor issue that can be easily worked around. These issues can be addressed as time allows.
-
- Lowest: Applies to trivial problems with minimal or no impact on progress. These issues can be addressed as time allows.
By understanding these priority levels, teams can efficiently allocate resources and tackle issues based on urgency and impact.
Closing a story:
We can close a story if:
-
- all linked bugs got fixed;
-
- all remaining open tickets are low priority and/or not added in this sprint or release (after the product owner has reviewed them);
-
- tickets were reviewed and not considered fixed in the current sprint.
Ad-hoc work/testing:
- Check the Testing, Rework Needed, Blocked, and Code Review columns to see if we need to ping somebody or transition tickets into other states.
- Make a filter with all the non-closed project-related tickets and validate them again to see if we need to either update or close them.
- Once we validate them, we should add a label like novValidated (which stands for, November validated, for example).
- *Make sure to add the labels, links, or comments properly.
- While doing this, you might find other bugs while validating the old ones.
Sprint vs Kanban Boards: Different Approaches to Triage
JIRA offers two main types of boards: Sprint and Kanban. Both boards are used to visualize and manage the workflow but differ in their approach to task management and triaging. Understanding these differences is crucial when working with the QA team.
Sprint Board
A Sprint board is used in Scrum, an Agile framework where work is organized into fixed-length iterations called sprints. In this board, tasks are planned for each sprint, and the team commits to completing a certain amount of work during that sprint.
When it comes to triaging items from the QA team:
- Backlog Triage: The product owner, along with the development and QA teams, reviews the backlog to prioritize and select items for the next sprint. Items are moved from the Backlog to the Selected for Development column.
- QA Feedback: If the QA team finds issues during testing, they move the items back to the In Progress column and leave comments for the developers. The developers address the issues and move the items back to the In Review column for retesting.
Kanban Board
A Kanban board is used in Kanban, an Agile methodology emphasizing continuous delivery and flow. In this board, work items are pulled from the backlog as soon as the team has the capacity to handle them.
When it comes to triaging items from the QA team:
- Continuous Triage: The product owner continuously reviews and prioritizes the backlog. There’s no need to wait for a sprint planning meeting. Items are moved from the Backlog to the Selected for Development column as soon as the team can handle them.
- QA Feedback: If the QA team finds issues during testing, they move the items back to the In Progress column and leave comments for the developers. The developers address the issues and move the items back to the In Review column for retesting.
In both board styles (Sprint or Kanban), it’s essential to have a clear communication channel between the development and QA teams. This ensures issues are addressed promptly and the workflow remains smooth and efficient.
By understanding the differences between Sprint and Kanban boards and how they handle triaging, teams can choose the best approach for their projects and improve their collaboration with the QA team.
Stay Updated with the Latest in QA
The world of software testing and quality assurance is ever-evolving. To stay abreast of the latest methodologies, tools, and best practices, bookmark our blog. We’re committed to providing in-depth insights, expert opinions, and trend analysis that can help you refine your software quality processes.
Delve deeper into a range of specialized services we offer, tailored to meet the diverse needs of modern businesses. As well, hear what our clients have to say about us on Clutch!