The definination of "Acceptance Criteria" in Agile

  • Acceptance Criteria Definition 1: “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” (via Microsoft Press)
  • Acceptance Criteria Definition 2: “Pre-established standards or requirements a product or project must meet.” (via Google)

My Own opinion:

The second definition may be considered the main definition, "Acceptance Criteria" is nothing but the usual functional, and non-functional requirements.


The purpose of acceptance criteria is to articulate precisely when the user story is 'done' from the product owner's perspective.

They should translate into 'acceptance tests’ that a tester (or quality assurance tester) can use to verify the quality of a feature.

A tester should be involved in writing them, but it is a product owner's responsibility to produce them.

Agile business analysts are very helpful in assisting product owners and extracting the right information for user stories.

Acceptance Criteria template:

|  A <role> should <see/be able to do> the following: 
|     - <AC1> 
|     - <AC2>
|     - <AC...> 
| 
|  Edge Cases: 
|    - <EC1> 
|    - <EC2> 

|    - <EC...>

Example in a user story:



Refrences:
http://pashunconsulting.co.uk/blog/productbacklog.html
https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/
Paul VII. Agile Product Management: User Stories:  How to capture, and manage requirements for Agile Product Management and Business Analysis with Scrum (scrum, ... development, agile software development) (p. 31). Pashun Consulting Ltd.. Kindle Edition. 

Comments

Popular posts from this blog

Maxpooling vs minpooling vs average pooling

Percentiles, Deciles, and Quartiles

Understand the Softmax Function in Minutes