Holiday Notice

ICAgile's offices will be closed December 25th through January 1st.

Article

Acceptance Criteria for Beginners

October 04, 2024

|

Emily May

How do you determine when a task or project is complete? If you don’t have a concrete answer to this question, it’s time to learn about acceptance criteria. 

At ICAgile, we’re all for flexibility in the workplace. But when it comes to our tasks and projects, it’s important to us that they are complete and correct. That’s why we take advantage of the simple practice of acceptance criteria.

This article covers everything you need to know about acceptance criteria: what it is, how to write it, and examples. 

What Is Acceptance Criteria?

Acceptance criteria are a list of requirements that team member(s) need to meet to consider a piece of work as ‘done.’ You can think of acceptance criteria as a checklist for the most critical outcomes of a task or project. After you cross off every item on the checklist, you can send your work for review or consider it complete. 

Many teams include acceptance criteria within their user stories. Pairing user stories and acceptance criteria can help teams view their acceptance criteria from the end-user's perspective. 

Acceptance criteria should be:

  • Measurable
  • Customer-centric
  • Relevant
  • Concise

The major benefit of leveraging acceptance criteria is accountability. Teams know what they need to accomplish individually and collectively to consider a piece of work complete. The clarity also improves transparency, planning, prioritization, and work quality standards.

How to Write Acceptance Criteria: Step-by-Step

The steps outlined in this section will prepare you to start writing acceptance criteria and incorporate the practice into your workflow. 

Step 1: Define the Work

screenshot of a card showing the work being defined

The first step to writing acceptance criteria is considering the task at hand. Acceptance criteria should be unique to each cluster of work, unlike a definition of done, which provides high-level objectives that can apply to multiple projects. 

User stories outline the who, what, and why of the work that you need to complete. This information makes it easier to brainstorm the conditions you need to meet to consider that work complete. 

The exploration stage may also involve collaborating with your team members or collecting feedback to ensure the user story is accurate. 

The big-picture goal of the user story needs to be clear before moving to the next step. The figure above is an example of a complete user story. 

Step 2: Write Your Acceptance Criteria

screenshot that shows the work in the previous image but with the acceptance criteria defined

With a complete user story, it’s time to brainstorm your acceptance criteria. You’ll need to narrow down potential conditions that signal the work is complete or ready for review. 

User stories describe the direct benefit the work will provide to the customer. The acceptance criteria are used as measures to achieve that benefit. The challenge here is to pull out the measurable and testable actions of the work. 

For example, suppose the goal of your user story is to build an FAQ page so that your customer has the upfront information they need to make a buying decision. An appropriate set of acceptance criteria can include ensuring all ten commonly asked questions are answered in the copy of the new webpage and having the new web page coded and ready for review, as seen in the illustration above. 

Acceptance criteria are hyper-specific, so team members can easily distinguish between incomplete and finished work. 


After identifying your conditions, it’s time to write your acceptance criteria. You may consider creating an acceptance criteria template or guide for your team to refer back to as necessary. 

Acceptance criteria should be short and easily understood by the entire team. Try to limit each condition to one sentence. 

Additionally, consider the customer’s perspective when writing your acceptance criteria. Ensure your criteria align with the customer pain points outlined in the user story. 

Ready to put pen to paper (or finger to keyboard)? The next stage is to choose a preferred style for writing the acceptance criteria. 

Acceptance Criteria Examples

cartoon of someone looking at different cards of work and acceptance criteria

Given-When-Then Format

One popular format for writing acceptance criteria is the “given-when-then” format. The style is a standard structure for scenario-based acceptance criteria or test cases, especially for development teams rolling out new features.

The format includes the following components: 

Given: How the scenario starts. 

When: The change to the scenario. 

Then: The result of the change. 


Here’s an example of a user story we’ll use to write our acceptance criteria:

User story title: Publish an article about acceptance criteria

User story description: As a learner who is new to acceptance criteria, I want to know what it is and how to write it so that I can begin incorporating the practice into my project management/user stories. 

Given-When-Then Format Example

Given the article is ready for publication,

When I publish the article on the website,

Then, the article will be visible to readers on the website. 


Given the article is published on the website,

When I schedule the article for sharing on social media,

Then, the article will be visible to followers on social media.

Bullet List Format

cartoon of a person looking at different bulleted lists

Your team can also write acceptance criteria as a checklist or bullet list. This format may be more convenient for user stories with multiple requirements. 

The format is as approachable as it sounds. Write each condition on a separate line. Be sure the criteria are clear and measurable. 

Let’s use the same user story to write acceptance criteria in a different format:

User story title: Publish an article about acceptance criteria

User story description: As a learner who is new to acceptance criteria, I want to know what it is and how to write it so that I can begin incorporating the practice into my project management/user stories. 

Bullet List Format Example

  • Article is published on website
  • Article is scheduled for sharing on social media

We utilize the bullet list format in the marketing team at ICAgile. This format is quick to write and easy for all team members to understand. 

Ultimately, it’s about finding a style that works for your team. Experiment, collect feedback, and adapt your approach as necessary. 

Conclusion

cartoon of a person considering their acceptance criteria

Acceptance criteria help teams validate that a user story is complete. These conditions promote improved productivity and value delivery by focusing on essential deliverables. 

If you enjoyed learning about acceptance criteria, our Agile Fundamentals class might suit you. The course covers foundational concepts that improve your processes, customer value, and adaptability. 

Are you looking for more advanced knowledge? Consider our Agile Product Ownership course, which helps students identify, prioritize, and validate customer value. 

You’ll get certified and be able to bring what you learn back to your team. Explore our Find a Class page to secure your seat. 

Happy learning!

Elevate Your Learning

Join our community of agile learners and get the latest news and resources delivered straight to your inbox.

* indicates required
TAGGED AS:
Foundations, Agile Fundamentals, Agile Product Ownership

About the author

Emily May | ICAgile, Marketing Specialist
Emily May is a Marketing Specialist at ICAgile, where she helps educate learners on their agile journey through content. With an eclectic background in communications supporting small business marketing efforts, she hopes to inspire readers to initiate more empathy, productivity, and creativity in the workplace for improved internal and external outcomes.

Suggested Resources