1. Home
  2. Training Library
  3. Business Management
  4. Courses
  5. Jira Essentials for Agile Teams

Acceptance Criteria

Developed with

The course is part of these learning paths

Applying AGILE Techniques to Build a DevOps Practice
DevOps Playbook - Moving to a DevOps Culture
Start course
Duration4h 1m


This course is designed for users who are already able to create, update and search for issues in Jira but now want to understand how to use Jira to control, manage, and maximize the effectiveness of their agile projects. We will look at using Jira in Scrum and Kanban projects and how Jira can be a powerful aid in the pursuit of empirical process control.

If you have any feedback relating to this course, feel free to contact us at support@cloudacademy.com.

Learning Objectives

  • Review Agile, Scrum, and Kanban practices and how Jira can be used in conjunction with them
  • Understand how Jira can be used to capture Epics, Stories, Tasks, and Acceptance Criteria
  • Understand how to use Jira to manage Scrum and Kanban projects
  • Learn how to use the Jira dashboard and tools

Intended Audience

Anyone looking to improve the way they use Jira to manage their workflows and projects, through the use of agile practices. 


To get those most out of this course, you should have a basic understanding of agile and Jira.


Acceptance criteria are those conditions that have to be met to allow a user story to be marked as done. So defining done, defining when we know that the user story is okay, makes the story testable. It's some required set of criteria to be met as specified. To be met specified by the product owners, stakeholders, designers and architects. An acceptance criteria needs to be SMART, another sets of acronyms, specific, measurable, achievable, reasonable and time-bound.

So we always say that about acceptance criteria, that it needs to be measurable, we need to be able to achieve them, reasonable time, time-bound. Acceptance criteria typically, the functional criteria, administrators should be able to create new users, a user must include a username and email, a first name, and a last name. So these are sort of functional criteria. You'll often have non functional criteria. And you've probably seen a mixture of the two in those requirements that you were just looking at, in the QA cinemas.

Delete buttons should be red, modal boxes should be cancelable, all of that kind of stuff, and performance related criteria. So the response time should be two seconds, it should respond within two seconds. So all of these things would be different kinds of acceptance criteria. Captured and recorded in its raw form, supplied by key stakeholders. And acceptance criteria can form the basis of a behavior driven development analysis, which we always say. And in behavior driven development, we use a language called Gherkin, which I've already shown you and I won't spend a huge amount of time on this, I know you wanna see more JIRA, but Gherkin is this common language used to define features and their scenarios. And it uses this given, when, then analysis. And BDD is all about the conversation. It's all about getting the business, the developers, and the testers involved, we talked about this with user stories earlier, coming up with all of these examples.

So it's great to define who the actors are, what they wanna do, and why they wanna do it. But also, we need to have some examples of how it's supposed to work. And this only those examples that will be sufficiently illustrative. Now you could just write your examples, you could just write a whole lot of sentences. It should work like this.

So when you do this, then this should happen, and we should then make it look like that. So yeah, you should, you could just write your examples and be illustrative in a bunch of sentences. But the reason why we use a defined language is to keep it consistent. And that's really what comes out of a process where we're trying to develop, do behavior driven development. We might actually get a whole bunch of questions out of this process, which are any unknowns.

So if we had some criteria, books can be added to the cart. Gherkin might describe, which is this language here. Gherkin might describe that more formally, as given my shopping basket is empty, when I add the book BDD is fun to the basket, then the shopping basket should contain one copy of BDD is fun. Now you might not be as specific as that. But, just to be, it just makes it a bit more kind of illustrative to me, for us to put that in. But you can see that we're giving a very clear, consistent example.

So defining scenarios is what we're talking about. And this is what you would put into, or you might document when you're documenting a requirement or a user story in JIRA. So you define your scenario given when, then, and you can have ands in there, as well. Gherkin uses those key words. This isn't a course on Gherkin, but it's just to introduce you to it.

So we've got given, when, and then and and, but scenario and background and feature, I definitely encourage you to look into this. It certainly improves the quality of the requirements that you write. And so there's some examples of how you might write an example or scenario which has got lots of acceptance criteria built into it. You may not even realize you're reading acceptance criteria. But, I mean, potentially you could take this to a board member, and the board member could look at it and go "Yeah, that's pretty much how we want it to work."

About the Author
Learning paths6

QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.