Understanding what acceptance criteria is and isn’t, how to write effective criteria and the easiest way to include acceptance criteria in Jira provides a tool for ensuring that developed stories meet customer expectations, as well as improving developers' productivity by removing ambiguity about when a story is complete.
What is Acceptance Criteria?
In Agile development, acceptance criteria is a predetermined list of requirements that must be met for a story to be considered complete. Using acceptance criteria provides clarity ensuring that all stakeholders have consensus about what the completed feature should be.
Acceptance Criteria vs Definition of Done
Acceptance criteria is a similar concept to Definition of Done, with one important distinction: Acceptance criteria are unique to each story. Acceptance Criteria and Definition of Done both identify elements that need to be in place before a story can be considered complete, however Definition of Done items are likely to be consistent across stories (“Code has been peer reviewed” , “Feature works in all supported browsers,” etc.). Acceptance criteria test that specific case put forward in the story has been met (“When logged in as a administrator, I can change permissions for who can…”). Both the definition of done and the acceptance criteria need to be met before a story is considered complete.
How to Create Acceptance Criteria
How useful your acceptance criteria are will depend on how well they’re written. To serve their purpose, acceptance criteria need to be:
- Specific – Describe the blank state, the action and the behavior that it triggers. What does the button look like before and after you click it, etc.
- Testable – You should be able to answer yes or no as to whether a criterion was met.
- Clear – Acceptance criteria are only effective if everyone has the same understanding of what they mean. Using precise, consistent language provides clarity so that everyone has the same vision of how the completed feature should work.
- Aligned with the story – Since the goal of using acceptance criteria is to see if the use case described in the story has been met, your criteria should align with the story. A common formula for stories is, “As a (user role), I (action/feature), so that (benefit).” Your acceptance criteria should be written from the point of view of the user role in the story, and should test that described scenario is achieved.
- Thorough – Being thorough in your acceptance criteria can minimize the number of bugs that emerge later. Try to anticipate edge cases. Include negative criteria (what happens if the user does not take the intended action).
Now let’s take a look at a few examples.
Acceptance Criteria Examples
In this scenario, the user wants to be able to comment on a blog post.
Story: As a signed-in user I want to comment on a blog so I can give feedback.
Acceptance criteria:
- When I open the page with a specific blog post the system shows the “Comments” section below the blog post with the list of comments added by other users
- The system shows the “Add a Comment” field with a “Submit” button in the top of the “Comments” section
- When I fill in the “Add a Comment” field with my comment and I click the “Submit” button, the system saves my comment and shows it at the top of the “Comments” section
- The system shows my username and profile picture to the left of my comment
- The system shows “Remove” and “Edit” buttons opposite my comment
- When I click the “Edit” button, the text field becomes enabled and I can edit my comment.
- When I click the “Delete ” button, a dialogue opens asking to “Confirm”. If I click “Confirm” my comment is deleted.
- If I click “Cancel”, the dialogue closes and my comment remains.
Now let’s look at an example for a feature in a Jira app.
Story: As a user with edit and create issue permissions, I want to convert a checklist item into a separate Jira issue.
Acceptance Criteria
- A “convert item button” is present for each checklist item.
- When I click the convert button the create issue dialogue opens.
- The Project for the new issue is set to the same project as the original issue.
- The summary field for the new issue is pre-populated with the text from the checklist item.
- The description will say, “Converted from checklist item in [ISSUE-KEY]” and the item description if there is one.
- If the create dialog includes a due date field, it will be pre-filled with the first valid date on the checklist item.
- The new issue will be created with a Relates to link to the issue that had the original checklist item.
- The original checklist item will be marked as complete, and will include a link to the newly created issue.
- If I close new issue dialogue without clicking Create, the checklist item will remain in its previous state.
Implement Acceptance Criteria on Jira Issues
Since you want your acceptance criteria to be clear, testable, and easily documented a checklist is the perfect tool for building acceptance criteria lists in Jira. Issue Checklist for Jira also gives you several options for making sure acceptance criteria get created and used (see the documentation for details):
- You can set the title of the checklist to “Acceptance criteria”
- If you prefer not to change the main title, you can create a mostly-empty template have it be automatically added to issues, prompting users to create the list of criteria
- Alternatively, you can append “Acceptance Criteria” as a heading to an existing template such as Definition of Done
- Finally, you can set a workflow validator to ensure that all checklist items, or all mandatory items, are complete before an issue is transitioned to done.
Using acceptance criteria effectively ensures that developed stories meet customer expectations and improves developers' productivity by removing ambiguity about when a story is complete. By following implementing acceptance criteria in Jira, you can enhance the clarity, testability, and overall quality of your Agile development process.
