Reading Time 5 minutes

Acceptance Criteria

Acceptance Criteria defines from an end user’s perspective, how a particular feature could be used. It focuses on business value, establishes the boundary of the feature’s scope and guides development. Acceptance criteria form the basis of acceptance testing which establishes the condition of success.

When the product owner verifies particular acceptance criteria and the developed feature passes the criteria, the development is considered a success.

Tips for writing Acceptance Criteria

Writing good acceptance criteria is the key to effectively testing the developed functionality. It allows the team members writing tests to understand the scope of the Product Backlog Item (PBI). Acceptance criteria could establish a boundary that helps to understand what’s included and what’s excluded from the scope of the PBI.

Here are some useful tips for writing acceptance criteria. Some of the Scrum teams I’ve worked with preferred to use it as a checklist for writing good and consistent acceptance criteria. I encourage the teams to keep revisiting and revising these tips to fit their need. I would also forewarn to avoid using these tips as fixed rules.

Here are some tips for writing acceptance criteria:

  • Each product backlog item or user story should have at least one acceptance criteria.
  • Acceptance Criteria is written before implementation – this is obvious yet frequently missed by teams.
  • Each criterion is independently testable.
  • Acceptance criteria has a clear Pass / Fail result.
  • It focuses on the end result – What. Not the solution approach – How.
  • Include functional as well as non-functional criteria.
  • Team members write the acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared-understanding of the user story.

Usually, acceptance criteria are developed jointly by the development team and the product owner. Who writes it, is not a matter of rules – what matters is – it should help to establish and communicate shared understanding between the product owner and the development team about solving a customer’s challenge or building product capability.

Product Backlog Item (User Story) example
  • LinkedIn
  • Twitter
  • Google+
  • reddit
  • Facebook

acceptance criteria example for Pay Balance Due PBI
  • LinkedIn
  • Twitter
  • Google+
  • reddit
  • Facebook

Example 1: User story and it’s acceptance criteria:

As a credit card holder, I want to view my statement (or account) balance, so that I can pay the balance due.

the acceptance criteria for this story could be:

  • Display statement balance upon authentication. Say for example $1560
  • Display total balance. For example $3560. Here the balance due from the current period is $2560 and past balance due is $2000.
  • Show Minimum payment due. For example $140
  • Show Payment due date. For example May 16th of the current month
  • Show error message if service not responding or timeout. For example ‘Sorry, something went wrong with the service. Please try again.’
User Story example 2
  • LinkedIn
  • Twitter
  • Google+
  • reddit
  • Facebook

acceptance criteria example for student performance PBI
  • LinkedIn
  • Twitter
  • Google+
  • reddit
  • Facebook

Example 2: User story and it’s acceptance criteria:

As a teacher, I want to generate assessment report, so I can evaluate student performance.

the acceptance criteria for this story could be:

  • Show a student’s current assessment score.
  • Display past assessment score of the student.
  • Provide an option to Print / Save / Share. (By the way, this could be split as a separate user story by itself).
  • Display error message if service not responding. (If a team chooses to add the Error Message as their definition of done for all stories – where ever applicable, it could be omitted from the acceptance criteria).

What is the right amount of Acceptance Criteria?

 

Well, if you’ve too many acceptance criteria for a single product backlog item (PBI), chances are you could split it into multiple PBIs. Have too many acceptance criteria as part of one story and chances are you’ll easily run into acceptance criteria that aren’t passing. That delays the delivery of that user story, which delays the feedback, ultimately increasing the risk of failure. I recommend, whenever you have got a chance, please go ahead and split the user story right there. You can thank me later 🙂

Splitting user stories helps in keeping each user story small, improves chances of delivering it early, seeking feedback faster, hence reduces risk. Yes, there is effort involved in splitting the user stories as well.

Hence, the PO and the development team have to identify for each user story, what is a barely sufficient detail of acceptance criteria. Photo source: Kenny Rubin, Innolution where Ken discusses the pros and cons of adding too many details versus no detail and establishes the need to identify what is barely sufficient detail to get started.

acceptance criteria detail for user stories
  • LinkedIn
  • Twitter
  • Google+
  • reddit
  • Facebook
Share This

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

Awesome. You've successfully subscribed.