Acceptance Criteria - Revision history

User at 10:25, 17 January 2023

2023-01-17T10:25:29Z

User at 10:24, 17 January 2023

2023-01-17T10:24:56Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T13:27:49Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User: Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.

2018-11-27T17:23:52Z

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.

New page

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.<ref>Definition - What is Acceptance Criteria? [https://www.leadingagile.com/2014/09/acceptance-criteria/ Leading Agile]</ref>

Acceptance Criteria may reference what is in the project’s other User Stories or design documents to provide details, but should not be a re-hash of them. They should be relatively high-level while still providing enough detail to be useful. They should include:
*Functional Criteria: Identify specific user tasks, functions or business processes that must be in place. A functional criterion might be “A user is able to access a list of available reports.” A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
*Non-functional Criteria: Identify specific non-functional conditions the implementation must meet, such as design elements. A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
*Performance Criteria: If specific performance is critical to the acceptance of a user story, it should be included. This is often measured as a response time, and should be spelled out as a threshold such as “
Acceptance Criteria should state intent, but not a solution (e.g., “A manager can approve or disapprove an audit form” rather than “A manager can click an ‘Approve/Disapprove’ radio button to approve an audit form”). The criteria should be independent of the implementation: ideally the phrasing should be the same regardless of target platform.<ref>Explaining Acceptance Criteria [https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ Segue Teachnologies]</ref>

'''Writing Effective Acceptance Criteria'''<ref> Tips on writing effective acceptance criteria[https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important Maryna Z.,Dmitriy G.]</ref>

*Keep your criteria well-defined so any member of the project team understands the idea you’re trying to convey.
*Keep the criteria realistic and achievable. Define the minimum piece of functionality you’re able to deliver and stick to it. On the other hand, don’t try to describe every detail since you risk cluttering up your backlog and getting buried under many small tasks.
*Coordinate with all the stakeholders so your acceptance criteria are based on consensus.
*Create measurable criteria that allow you to adequately estimate development time so you’re able to stay within budget and time constraints.
*Consider providing checklists that enable you to see what user stories are covered with acceptance criteria.

[[File: Acceptance Criteria.png|Acceptance Criteria]]<br />
source: [https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important RubyGarage]

'''The Use of Acceptance Criteria'''<ref>What are Acceptance Criteria Used For? [https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important RubyGarage]</ref>

*To define boundaries. Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired, meaning that a user story is completed.
*To reach consensus. Having acceptance criteria synchronizes the development team with the client. The team knows exactly what conditions should be met, just as the client knows what to expect from the app.
*To serve as a basis for tests. Last but not least, acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected.
*To allow for accurate planning and estimation. Acceptance criteria scenarios allow for the correct division of user stories into tasks so user stories are correctly estimated and planned.

'''Characteristics of Effective Acceptance Criteria'''<ref>What are the Characteristics of an Effective Acceptance Criteria? [https://medium.freecodecamp.org/the-acceptance-criteria-for-writing-acceptance-criteria-6eae9d497814Free Code Camp]</ref>

*Testable with clearly defined pass/fail results
Have testable criteria. This allows testers to properly confirm that all of the desired conditions have been fulfilled. If criteria were not testable, then there would be no way for verification. These criteria should either be met or not met. A developer should know the point in which the criterion has been achieved. Any ambiguity may prolong effort on the story. For example, an acceptance criterion states “increase the number of entries available in a drop-down menu”. The developer would have no idea how many new entries to add and may take the liberty to assume a number based on his experience with the product. Likewise, a manual tester may take the same liberty and assume a different definition of increase. This results in a confusion that will circle back to the product owner.
*Unambiguous and concise
This is where writing acceptance criteria become an art. Academic essays stress the importance of clarity and succinctness. Similarly, writing acceptance criteria mandates the same level of organization and care. Similar to writing a literary piece, the audience must be kept in mind. Those reading the acceptance criteria must understand what is written. Otherwise, those words are completely useless. If they are long-winded and filled with jargon, then the main points of the outlined conditions may not come across. Many people can overlook essential details in a sea of words when pressed for time. Even when not pressed for time, many people can easily gloss over long blurbs. Instead of putting the blame on others’ lack of careful reading, one can proactively present acceptance criteria that are easy to read, straight to the point, and devoid of superfluous details.
*Establish shared understanding
This is probably the most important characteristic and the one most taken for granted. If all the members of the team are not on the same page, then process and productivity become jeopardized. Having the development team review acceptance criteria before moving forward with the story minimizes confusion. Clarifications should be made about the criteria, and the criteria should be updated accordingly.

'''Benefits of Acceptance Criteria'''<ref>Benefits of Acceptance Criteria to software development teams [https://existek.com/blog/what-are-acceptance-criteria/ Existek]</ref>

*The acceptance criteria enable the development team to identify the user story which they can use as a reference of whether the product functionality is as required. Since the user story is the primary objective of the software development process, therefore the team can use it to assess the progress and the product if it is as desired.
*Unity between the client and the development team is synchronized as the client has specific expectations from the team while the team has detailed scenarios of the development process and the final product required.
*The software development project is usually divided into tasks which after each are completed, it has to be confirmed that they meet the requirement of the project development scope and this is made possible by the use of the criteria of acceptance.
*Before any software begins to be developed, some planning is required and estimation of resources and time. Acceptance criteria allow easy division of tasks which can then be easily budgeted and assigned for time.

===References===
<references/>

===Further Reading===
*Acceptance Criteria vs. Acceptance Tests – Know the Difference [https://www.thinksys.com/qa-testing/acceptance-criteria-vs-acceptance-tests/ ThinkSys]
*7 Tips for Writing Acceptance Criteria with Examples [http://agileforgrowth.com/blog/acceptance-criteria-checklist/ Agile for Growth]
*The Importance of Having Clearly Defined Acceptance Criteria in Your Projects [https://www.simplilearn.com/importance-of-having-clearly-defined-acceptance-criteria-in-projects-article Simplilearn]

@@ Line 1: / Line 1: @@
 == What are Acceptance Criteria? ==
-Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.<ref>Definition - What is Acceptance Criteria? [https://www.leadingagile.com/2014/09/acceptance-criteria/ Leading Agile]</ref>
+Acceptance Criteria are the conditions that a [[software]] product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.<ref>Definition - What is Acceptance Criteria? [https://www.leadingagile.com/2014/09/acceptance-criteria/ Leading Agile]</ref>
 Acceptance Criteria may reference what is in the project’s other User Stories or design documents to provide details, but should not be a re-hash of them. They should be relatively high-level while still providing enough detail to be useful. They should include:

@@ Line 1: / Line 1: @@
-Acceptance Criteria are the conditions that a [[software]] [[product]] must satisfy to be accepted by a user, [[customer]], or in the case of [[system]] level functionality, the consuming system. Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.<ref>Definition - What is Acceptance Criteria? [https://www.leadingagile.com/2014/09/acceptance-criteria/ Leading Agile]</ref>
+== What are Acceptance Criteria? ==
-Acceptance Criteria may reference what is in the project’s other User Stories or [[design]] documents to provide details, but should not be a re-hash of them. They should be relatively high-level while still providing enough detail to be useful. They should include:
+Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.<ref>Definition - What is Acceptance Criteria? [https://www.leadingagile.com/2014/09/acceptance-criteria/ Leading Agile]</ref>
-*Functional Criteria: Identify specific user tasks, functions or [[business]] processes that must be in place. A functional criterion might be “A user is able to access a list of available reports.” A non-functional criterion might be “Edit buttons and [[Workflow]] buttons comply with the Site Button Design.”
 *Non-functional Criteria: Identify specific non-functional conditions the implementation must meet, such as design elements. A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
-*Performance Criteria: If specific performance is critical to the acceptance of a user story, it should be included. This is often measured as a response time, and should be spelled out as a [[threshold]] such as “
+*Performance Criteria: If specific performance is critical to the acceptance of a user story, it should be included. This is often measured as a response time, and should be spelled out as a threshold such as “
-Acceptance Criteria should state intent, but not a solution (e.g., “A [[manager]] can approve or disapprove an audit form” rather than “A manager can click an ‘Approve/Disapprove’ radio button to approve an audit form”). The criteria should be independent of the implementation: ideally the phrasing should be the same regardless of [[target]] platform.<ref>Explaining Acceptance Criteria [https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ Segue Teachnologies]</ref>
+Acceptance Criteria should state intent, but not a solution (e.g., “A manager can approve or disapprove an audit form” rather than “A manager can click an ‘Approve/Disapprove’ radio button to approve an audit form”). The criteria should be independent of the implementation: ideally the phrasing should be the same regardless of target platform.<ref>Explaining Acceptance Criteria [https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ Segue Teachnologies]</ref>
@@ Line 11: / Line 13: @@
 *Keep your criteria well-defined so any member of the project team understands the idea you’re trying to convey.
-*Keep the criteria realistic and achievable. Define the minimum piece of functionality you’re able to deliver and stick to it. On the other hand, don’t try to describe every detail since you [[risk]] cluttering up your backlog and getting buried under many small tasks.
+*Keep the criteria realistic and achievable. Define the minimum piece of functionality you’re able to deliver and stick to it. On the other hand, don’t try to describe every detail since you risk cluttering up your backlog and getting buried under many small tasks.
 *Coordinate with all the stakeholders so your acceptance criteria are based on consensus.
-*Create measurable criteria that allow you to adequately estimate development time so you’re able to stay within [[budget]] and time constraints.
+*Create measurable criteria that allow you to adequately estimate development time so you’re able to stay within budget and time constraints.
 *Consider providing checklists that enable you to see what user stories are covered with acceptance criteria.
@@ Line 22: / Line 24: @@
 '''The Use of Acceptance Criteria'''<ref>What are Acceptance Criteria Used For? [https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important RubyGarage]</ref>
-*To define boundaries. Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the [[application]] functions as desired, meaning that a user story is completed.
+*To define boundaries. Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired, meaning that a user story is completed.
 *To reach consensus. Having acceptance criteria synchronizes the development team with the client. The team knows exactly what conditions should be met, just as the client knows what to expect from the app.
 *To serve as a basis for tests. Last but not least, acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected.
@@ Line 33: / Line 35: @@
 Have testable criteria. This allows testers to properly confirm that all of the desired conditions have been fulfilled. If criteria were not testable, then there would be no way for verification. These criteria should either be met or not met. A developer should know the point in which the criterion has been achieved. Any ambiguity may prolong effort on the story. For example, an acceptance criterion states “increase the number of entries available in a drop-down menu”. The developer would have no idea how many new entries to add and may take the liberty to assume a number based on his experience with the product. Likewise, a manual tester may take the same liberty and assume a different definition of increase. This results in a confusion that will circle back to the product owner.
 *Unambiguous and concise
-This is where writing acceptance criteria become an art. Academic essays stress the importance of clarity and succinctness. Similarly, writing acceptance criteria mandates the same level of [[organization]] and care. Similar to writing a literary piece, the audience must be kept in mind. Those reading the acceptance criteria must understand what is written. Otherwise, those words are completely useless. If they are long-winded and filled with jargon, then the main points of the outlined conditions may not come across. Many people can overlook essential details in a sea of words when pressed for time. Even when not pressed for time, many people can easily gloss over long blurbs. Instead of putting the blame on others’ lack of careful reading, one can proactively present acceptance criteria that are easy to read, straight to the point, and devoid of superfluous details.
+This is where writing acceptance criteria become an art. Academic essays stress the importance of clarity and succinctness. Similarly, writing acceptance criteria mandates the same level of organization and care. Similar to writing a literary piece, the audience must be kept in mind. Those reading the acceptance criteria must understand what is written. Otherwise, those words are completely useless. If they are long-winded and filled with jargon, then the main points of the outlined conditions may not come across. Many people can overlook essential details in a sea of words when pressed for time. Even when not pressed for time, many people can easily gloss over long blurbs. Instead of putting the blame on others’ lack of careful reading, one can proactively present acceptance criteria that are easy to read, straight to the point, and devoid of superfluous details.
 *Establish shared understanding
-This is probably the most important characteristic and the one most taken for granted. If all the members of the team are not on the same page, then [[process]] and [[productivity]] become jeopardized. Having the development team review acceptance criteria before moving forward with the story minimizes confusion. Clarifications should be made about the criteria, and the criteria should be updated accordingly.
+This is probably the most important characteristic and the one most taken for granted. If all the members of the team are not on the same page, then process and productivity become jeopardized. Having the development team review acceptance criteria before moving forward with the story minimizes confusion. Clarifications should be made about the criteria, and the criteria should be updated accordingly.
 '''Benefits of Acceptance Criteria'''<ref>Benefits of Acceptance Criteria to software development teams [https://existek.com/blog/what-are-acceptance-criteria/ Existek]</ref>
-*The acceptance criteria enable the development team to identify the user story which they can use as a reference of whether the product functionality is as required. Since the user story is the primary [[objective]] of the software development process, therefore the team can use it to assess the progress and the product if it is as desired.
+*The acceptance criteria enable the development team to identify the user story which they can use as a reference of whether the product functionality is as required. Since the user story is the primary objective of the software development process, therefore the team can use it to assess the progress and the product if it is as desired.
 *Unity between the client and the development team is synchronized as the client has specific expectations from the team while the team has detailed scenarios of the development process and the final product required.
-*The software development project is usually divided into tasks which after each are completed, it has to be confirmed that they meet the [[requirement]] of the project development scope and this is made possible by the use of the criteria of acceptance.
+*The software development project is usually divided into tasks which after each are completed, it has to be confirmed that they meet the requirement of the project development scope and this is made possible by the use of the criteria of acceptance.
 *Before any software begins to be developed, some planning is required and estimation of resources and time. Acceptance criteria allow easy division of tasks which can then be easily budgeted and assigned for time.
@@ Line 51: / Line 58: @@
 ===Further Reading===
-*Acceptance Criteria vs. Acceptance Tests – Know the Difference [https://www.thinksys.com/qa-testing/acceptance-criteria-vs-acceptance-tests/ ThinkSys]
+*[https://www.thinksys.com/qa-testing/acceptance-criteria-vs-acceptance-tests/ Acceptance Criteria vs. Acceptance Tests – Know the Difference -ThinkSys]
-*7 Tips for Writing Acceptance Criteria with Examples [http://agileforgrowth.com/blog/acceptance-criteria-checklist/ Agile for Growth]
+*[http://agileforgrowth.com/blog/acceptance-criteria-checklist/ 7 Tips for Writing Acceptance Criteria with Examples -Agile for Growth]
-*The Importance of Having Clearly Defined Acceptance Criteria in Your Projects [https://www.simplilearn.com/importance-of-having-clearly-defined-acceptance-criteria-in-projects-article Simplilearn]
+*[https://www.simplilearn.com/importance-of-having-clearly-defined-acceptance-criteria-in-projects-article The Importance of Having Clearly Defined Acceptance Criteria in Your Projects -Simplilearn]