Top 6 things to track with checklists in Jira issues

[#1]

Actionable checklists are a great enhancement of Jira issues. Rather than using bullet lists within the issue description or subtasks, they allow you to add multiple checklists and enhance your everyday workflow by checking off things that are completed. Checklists give you a clear overview of the tasks that have been done or that still need to be completed. Moreover, they can be saved as templates, so that they can be easily reused in other Jira issues. Here are the top 6 things you can and should be tracking in your projects with checklists.

Acceptance criteria

One great thing to track with a checklist in your issue is the acceptance criteria list. Agile teams use them to define conditions or tasks that must be fulfilled, in order to consider the issue completed. Acceptance criteria are a helpful summary of things that need to be done, usually created on the basis of a related user story. Having them written down as a checklist ensures that neither the developer nor the tester misses a single point. With a checklist, you can simply tick off the things that are finished, and get immediate insight into what still needs to be done.

Definition of Done

Similar to the acceptance criteria, the definition of done is a list of tasks that have to be taken care of in order to consider the issue as “Done”. This is an important definition in the agile methodologies, as it’s crucial for artifact transparency. When the team says that an issue is “Done”, everyone must be on the same page on what “Done” actually means. Has that issue been tested? If so, how? Has it been documented? Has it been released? “Done” may stand for different things in projects and that’s why it’s important that both the team and the stakeholders understand what truly translates into “Done”.

Definition of Done is often kept outside of the Jira issue. If the DoD is not constantly reviewed, it’s easy to forget about it and start producing increments of software that aren’t actually “Done” as per the product definition. That’s where a checklist can come to the rescue. Not only can you save the Definition of Done as a template, to re-use in any further issue. You can easily configure your project to have the Definition of Done checklist added to any created issue. Moreover, you can configure a different template to be added based on the issue type of the created issue. Definition of Done may slightly differ depending on the issue type. For example, bug fixes may not need to have the documentation updated, as no new feature is added. However, you may want to update your internal documents, like the root cause tracking, to help prevent similar issues in the future.

Definition of Ready

Definition of Ready is a less known sister of the Definition of Done. It contains a set of criteria that must be met, in order to consider the issue ready for development. Even though it is not an official requirement to maintain the Definition of Ready per the Scrum Guide, many agile teams establish one. There are many advantages to having it written down. DoR helps you maintain a high quality of your issues, by making sure that all the necessary research has been conducted and all the relevant information have been placed into the issue. For the same reason, it helps the team standardize the structure of issues, by making sure they contain all of the sections. Definition of Ready is also a great tool for the Product Owner who works with the team to prepare and groom the backlog for the upcoming sprint. It allows them to easily identify areas for improvement and work that still needs to be done, in order to allow the developers to start implementing the feature.

Testing points

As detailed as your acceptance criteria and definition of done lists can get, your testers need a broader view than just a scope of the implemented issue. Their task is not only to verify that the acceptance criteria have been met and that the Definition of Done is respected. They need to look for any problems and edge cases that the developers have missed or haven’t predicted. Moreover, they need to make sure that the change has not caused any regressions in other parts of the system. This is a tough task, but their job can be made easier with just a little help. As the developers are working on the issue, it is a perfect time to complete the testing points checklist. It can contain anything ranging from the edge cases to the affected components. The point is that the developer implementing the change has the best visibility into what parts of the system could have been affected. By passing it on to the Quality Assurance guys as a checklist of things to verify, they improve the chances of catching regressions and unpredicted failures.

This is as easy as it can get using checklists in your Jira issues. Just have your developers add items to the checklist as they are working on an issue, and once it reaches the testing step, the testers have direct visibility into things to consider while making sure everything is in order.

Releasing

Another great use of checklists is release tracking. Depending on how big is your project, how automated your release process is, and how often you release, the checklist can vary from very short to quite extensive. If your release process is not fully automated and you don’t release very often, it becomes very easy to forget an important step, what may be disastrous for the release and in some cases may require a quick patch release.

Checklists can be saved as a template, in order to reuse them later. You can easily load the “Release checklist” into your issue that tracks the release to make sure you don’t forget about any step.

Regression testing

A regression is a bug, that was introduced with an implementation of a new feature, an adjustment in another part of the system, or any other external event that caused a new problem. Regressions can refer to both typical bugs (e.g. feature xyz stopped working), but may also mean that a system starts operating slower than it used to. In order to tackle this problem, projects establish automated and manual tests for existing features. Executing them regularly helps raise the confidence that the system operates as expected.

With checklists and reusable templates, your regression testing plan can be easily stored and added to the issue when needed. It may contain a step-by-step guide to running regression tests or even consist of key features that need to be verified during regression tests.

Countless possibilities

No matter if you use Jira for your software project, service desk or any other business activity, you deal with repeatable tasks all the time. Employee onboarding, reporting, interview debrief - those are just a few examples. Whatever iterative tasks you are responsible for, checklists can make sure you never miss anything.

The Atlassian Marketplace offers many great apps that enhance the Jira issue view with checklists. One of them is Multiple Checklists for Jira that we have developed at SolDevelo and that is available for Jira Cloud and Jira Server.

[Urszula Kaczorek]

A great thing is that you don't have to be a technical person to make use from such checklists. In my daily work, most of issues are not repeatable, so creating your own, personalized TO DO list in an easy (and fast) way, which will be just legible for me and my team is a core improvement.