Acceptance Criteria

Developed with


Getting Started with Jira
Jira Essentials
PREVIEW10m 26s
User Stories
PREVIEW15m 37s
10m 18s
Start course

This course provides an introduction to Jira and covers user stories, user story mapping, epics, acceptance criteria, and MoSCoW prioritization. By the end of the course, you're going to have a good understanding of the features available in Jira and how to use them to manage your workflows.

If you have any feedback relating to this course, feel free to contact us at

Learning Objectives

  • Get a foundational understanding of Jira
  • Learn about user stories and the related acceptance criteria, constraints, and business goals
  • Learn what epics are and how stories roll up into them
  • Understand user story mapping and MoSCow prioritization

Intended Audience

This course is intended for anyone who wants to learn more about Jira and how it can be used as a tool to manage your workflows.


To get the 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 Paths

A world-leading tech and digital skills organization, we help many of the world’s leading companies to build their tech and digital capabilities via our range of world-class training courses, reskilling bootcamps, work-based learning programs, and apprenticeships. We also create bespoke solutions, blending elements to meet specific client needs.