By using this website, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Building Acceptance Criteria Lists in Jira

Acceptance Criteria in Jira differ from Definition of Done. But both can (and should) be easily added to your Jira issues.
min. read
Nov 27, 2023

Sometimes it’s clear when you’ve reached the end of the road. Sometimes it’s not. It’s also possible to go too far. The same is true for Jira issues. If the scope of a piece of work isn’t well defined, or if the product owner’s expectations aren’t clear, developers might mark an issue as complete only to have it rejected by the product manager.

Using Acceptance Criteria on a Jira issues removes ambiguity about the expectations and prompts developers to think about the feature from the user’s point of view.  Acceptance Criteria also signal up front what level of testing will need to be done before the feature can be released.  While your initial Acceptance Criteria will most likely focus on ensuring that feature delivers the expected behaviour (example: The user can update the field…), criteria can also refer to the overall user experience such as ensuring consistent and attractive UI, and undiminished performance.

Since Acceptance Criteria items need to be items that clearly pass or fail, a checklist is a perfect way to track them. Having them present on the Jira issue from the onset, means that the dev team can see the product owners expectations.

When to use Acceptance Criteria vs Definition of Done

While your Definition of Done is likely to be consistent across issues of the same type – lending itself to creating a default checklist template that is automatically added to issues of that type when they’re created;

Acceptance Criteria are specific to the individual user stories, so they need to be created separately on each issue.

Who Can Create Acceptance Criteria in Jira?

Since Acceptance Criteria are the means by which Product Owners convey their expectations to developers, it makes sense that only the product owner should be able to create or edit the list, but developers should be able to check off completed items. The Issue Checklist app, available on the Atlassian marketplace, lets you set specific permissions for who can Add, Edit, Delete, Toggle and View checklist items.

Simply go to Jira Settings > Apps and select Issue Checklist Permissions.  Use the toggle to Enable custom work on checklist permissions. This will allow you to set specific checklist permissions in each of your Jira projects:

  • In Company-managed/Classic projects navigate to Project Settings > Permissions and assign the appropriate role for each of the checklist permissions.

  • In Team-managed/Next-gen projects go to Project Settings > Access. Click Manage roles and Create role. Select the App permissions tab to configure the role.

Multiple Checklists on a Jira Issue

An issue may need multiple checklists on its journey from user story to fully developed feature. In fact, previous posts have discussed how you can use a checklist to create a Definition of Ready for stories in your backlog, and a Definition of Done for issues in your sprints. Issue Checklist for Jira  allows you to use multiple checklists while also using a default checklist template. This means you can create an automatically-added Definition of Done template for all stories in your project and then add individual Acceptance Criteria.

That way everyone knows when they’ve reached the end of the road.

Jennifer Choban

Join us on Social Media!