A How to Guide for Writing Acceptance Criteria with Examples

What is acceptance criteria?

Acceptance Criteria defines the requirements which must be met for the sprint deliverables to be accepted by the product owner. 

You’re at the end of the sprint. You and your team have worked hard to deliver new functionality based on the user story you were given. As the product owner presents it, there is confusion about how to take the right action or if it was successful. 😞

You might have created some incredible new functionality, but if it’s not presented at the right moment in the user journey, then the benefit is lost.

Clarity is a crucial ingredient in Scrum, especially clarity about whether or not something is done. Acceptance criteria supports this kind of completion clarity by providing clarity about the user experience of new functionality that results from a user story.

Acceptance Criteria and User Stories

Acceptance criteria and user stories are key tools used in Scrum to describe the work to be done. Let's take a closer look at how they're similar, how they're different, how they work together and then look at some examples.

Both acceptance criteria and user stories have a simple but effective format. They both bring clarity to the value you’re creating for the end-user.

How is acceptance criteria different than user stories in Scrum?

Acceptance criteria and user stories fundamentally answer different questions. They each contribute complementing aspects of clarity.

• A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
• Acceptance criteria focuses on the actions taken by the user to meet their goal. It emphasizes the what of the new functionality.

Acceptance criteria and user stories are a dynamic duo of user-centric development.

How do acceptance criteria and user stories work together?

Because acceptance criteria and user stories answer different questions, when combined, they provide a fuller picture of the work that must be done.

The user story really comes first because it answers the why. If there is no why, then the work isn't really delivering value. But once the why is clear and identifies the user's goals and motivation, the team must answer the question of what. What will they create to help the user achieve their goal?

The acceptance criteria takes a tighter focus on specifically how the interaction will be designed and what the end state will be.

Together user stories and  acceptance criteria answer the questions of

• Did we build the right thing?
• Did we build it right?

Examples of acceptance criteria and user stories being used together.

Here’s an example of using a user story from my post on writing good user stories.

User Story

• As a student studying project management,
• I want to understand the general ideas of Scrum,
• So that I can determine if something I want to pursue a certification in.

Acceptance Criteria

• Given that I’m reading through the What is Scrum Guide,
• When I click the FAQ section,
• Then I see a question about certification without having to scroll.

This example also illustrates how you can apply the tools of user stories and acceptance criteria to creative work like content creation. 

The user story is created first, and the acceptance criteria is built from it. They are a dynamic duo of user-centric development.

Acceptance Criteria and the Definition of Done.

The Definition of Done is another Scrum concept that many people ask how it compares to acceptance criteria. When it comes to using Scrum to get stuff done, Acceptance Criteria and the Definition of Done both play important roles

‍

How is acceptance criteria different than the definition of done in Scrum?

The definition of done is also a criterion. It outlines what must be true for any product backlog item to be considered “done.” This criterion is broad and flexible enough to be applied to all backlog items yet concrete and specific enough for it to be clear whether or not it has been met.

So the definition of done applies to all work done by a team and answers the question, “What are we committing to do every time we complete a task?”

In comparison acceptance criteria applies to a single task or product backlog item and answers the question, “What are we committing to do on this specific task?”

So you see acceptance criteria is specific to a given task and definition of done applies to all tasks. So every task should have both acceptance criteria and definition of done defining what it means for the task to be done. 

How do acceptance criteria and the definition of done work together?

Have you ever been on a project where everything seemed mostly done, but nothing seemed really done?

Acceptance criteria and the definition of done work together to tackle the challenge of work staying undone. Because it’s so frustrating when you expected something to be done, and it’s not. Or someone says it’s 80% done, but a week later and it’s still 80% done. 

The truth is… It’s either done or it’s not.

Acceptance criteria and the definition of done are two tools to help combat the challenge of undone work. When both are included on a given task, there should no longer be any ambiguity. If the task's acceptance criteria has been met and the team's definition of done requirements have been met, then the task is done. Anything short of that and it's not done yet.

Examples of acceptance criteria and the definition of done being used together.

Let’s look at an example of acceptance criteria and definition of done for a creative team delivering marketing collateral.

Will use the same acceptance criteria from above for a marketing campaign.

• Given that a customer is already receiving email communications,
• When they visit the site and engage content related to product X,
• Then they will be automatically subscribed to nurturing campaign highlighting that product.

So you can see this acceptance criteria is specific to a given task. If at the end of the sprint this isn’t how the functionality works, then the task isn’t done. Period.

Now how might the definition of done play a role here?

That same Scrum marketing team my have this as their definition of done.

• User testing performed and results shared with the client.
• At least one demo performed during the sprint for the client.
• Success criteria met
• Assets delivered to the client.
• Assets and design files archived in the proper folder.
• Product owner accepts the user story.
• Invoice submitted.
• Customer survey sent.
• Evaluation scheduled.

Remember the definition of done is the commitment of the whole Scrum team to every task. So for this to be called done it has to meet all the definition of done criteria as well. 

This can seem a little OP at first, but look back through the list. These are basic things that are just part of doing the job. However by explicitly stating them and committing to them as a team you can change the team culture around getting stuff done.

Leaning Scrum is a process

There are a lot of new terms when learning the Scrum essentials, and I hope this post helped clear up some of the vocabulary around acceptance criteria. If you want to learn more about Scrum in general, check out my What is Scrum? A Guide for Everyday People to Learn Scrum. If you have more questions, please feel free to reach out on LinkedIn.

Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 1-hour coaching session, and we can work together to identify a good next step for you.