Multiple Checklists for Jira is a great tool that introduces Jira checklists into Jira issues. Rather than using bullet lists within the issue description or subtasks, you can now easily add multiple, actionable Jira checklists and enhance your everyday workflow.
Jira 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 Multiple Checklists for Jira.
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 Multiple Checklists for Jira, 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 Multiple Checklists for Jira 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. With Multiple Checklists for Jira, you get all the flexibility you need.
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 of 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.
With Multiple Checklists for Jira, you can automatically add your “Definition of Ready” checklist to each new issue in Jira and track the progress on getting them ready for development. This also improves your Sprint planning meetings. Just one glimpse is enough to know what still needs to be done in the issue to make it ready for the development.
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 with Multiple Checklists for Jira. 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.
Another great use of checklists is the 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.
Multiple Checklists for Jira give you the possibility to save a checklist as a template in order to reuse it 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.
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 Multiple Checklists for Jira and checklist templates it offers, 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.
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, Multiple Checklists for Jira will make sure you never miss anything.
What other tasks have you managed to improve with Multiple Checklists for Jira?
We want to hear from you – firstname.lastname@example.org!