Acceptance Criteria of user stories in agile-methodologies

Definition of Acceptance Criteria in Agile Methodologies for user stories

The terms ‘Conditions of Satisfaction’ and ‘Acceptance Criteria’ used interchangeably.

They can be considered a clear description that will define value proposition, user flow or characteristic of the solution.

Acceptance criteria are acted as a catalyst for test cases and it should be testable. Acceptance criteria provide a detailed scope of the requirement, which help the team to understand the value and help the team to slice the user story horizontally.

The condition of satisfaction help to set expectations within the team as to when a team should consider something done. It helps the team to break down the user stories in task(s), if acceptance criteria are defined in detailed, then the team can provide better effort estimation for a user story, so development cycle can be shorter, resulting in no waste.

How to write acceptance criteria for a User Story in Agile?

The acceptance criteria is a must have ingredient for a user story. Acceptance criteria is a checklist that determine if all the parameters of a User Story and determine when a User Story is completed and working.

Before the developer can mark the User Story as ‘done’. All criteria must be fulfilled so that it is ensured that the User Story works as planned and tested.

The product owner is usually responsible for specifying what the acceptance criteria should be for each of the user stories.

When crafting perfect user story, acceptance criteria make the functionality pretty transparent, it help the product owner to find any missing point and validate the assumption. If any assumption is incorrect it helps to catch a little sooner.

Agile Acceptance Criteria Template

There is no template from the scrum about acceptance criteria, acceptance criteria is a detail description of system or feature put forward by the product owner, it’s a criterion against which the user story should be validated and tested.

What Acceptance criteria should be included

  • Negative scenarios of the functionality.
  • The impact of a user story to other features.
  • UX concerns
  • Functional and non-functional use cases
  • Performance concerns and guidelines.
  • What system/feature intend to do
  • System of feature doesn’t do anything, isn’t supposed to do
  • End-to-end user flow

What Agile Acceptance Criteria Should Not Include

Do not include following obvious stuff as your acceptance criteria for your user stories

  • Code Review was done
  • Non-blocker or major issues
  • Performance testing performed
  • Acceptance and functional testing done

Above checklist need to be included as part of DoD (definition of done), which serve as a checklist for overall sprint process, those shouldn’t be part of acceptance criteria

How to Write User Stories & acceptance Criteria

Acceptance criteria should be expressed very clearly, in simple language, without any ambiguity about the expected outcome. This ensures that the testers will be successful when they take the acceptance criteria and translate it into manual or automated test cases.

Simple and widely accepted format of user story template is

As a ____, I want ___, so that ____

Practical Example of User Story With Acceptance Criteria

Acceptance Criteria of user stories in agile-methodologies

Here is the detailed example of our user story with acceptance criteria

Example bellow is an implementation of a new feature called printing. This feature provides the user with printed format of a user story or a bug in presentable format

Practical example of acceptance criteria

“As a user I should have the option to print any item with all the details, comments, and other things. I should get printable view in browser and then should have the option to print into different formats”

Acceptance Criteria

  • All the item information should be visible including title, ID, description, comments, attachment names, linked items tasks/issues/epics etc, associated items, dependencies etc
  • On the preview page, I should option to print, download as
  • PDF
  • Word
  • XML(optional)
  • any other?

All the items type should be printable

  • User Story
  • Epic

In case of Epic, we will show the related user stories and show only, ID, Title, Responsible, Status and priority

  • Tasks
  • Issues

It should be possible to print the item details from almost anywhere, e.g.,

  • From boards widgets under context menu
  • In case of Epic or user story, from Epic or Backlog item context menu
  • From item detail view
  • From pop-up under context menu