Acceptance criteria: Difference between revisions
Ceopediabot (talk | contribs) m (Typos, typos fixed: ’s → 's (2), a authenticated → an authenticated) |
m (Text cleaning) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
'''Acceptance criteria''' are the criteria used in projects or contracts to establish whether job was done properly. Objectives of [[project]] or contract can be stated generally and be not precise enough to tell if task was done. For example, objective can state "to build a house with 3 bedrooms". But how large those bedrooms should be? What should be height? Is cellar/basement required? Is kitchen required? What [[technology]] should be used to build walls? Therefore, we [[need]] acceptance criteria which tell precisely when we agree that the contract/project is done. | '''Acceptance criteria''' are the criteria used in projects or contracts to establish whether job was done properly. Objectives of [[project]] or contract can be stated generally and be not precise enough to tell if task was done. For example, objective can state "to build a house with 3 bedrooms". But how large those bedrooms should be? What should be height? Is cellar/basement required? Is kitchen required? What [[technology]] should be used to build walls? Therefore, we [[need]] acceptance criteria which tell precisely when we agree that the contract/project is done. | ||
| Line 22: | Line 6: | ||
* performance criteria - related to [[efficiency]]. | * performance criteria - related to [[efficiency]]. | ||
== Acceptance criteria in scrum projects == | ==Acceptance criteria in scrum projects== | ||
In scrum, acceptance criteria are integral part of user stories. User stories are simple description of a [[product]] function, written from user's perspective. | In scrum, acceptance criteria are integral part of user stories. User stories are simple description of a [[product]] function, written from user's perspective. | ||
| Line 30: | Line 13: | ||
Composing acceptance criteria isn't essential only for defining the vision of a product from the customer's perspective. It is also important for team members to achieve good results. It's nothing unusual that different members of the team see a similar issue from various points. Good composed criteria can ensure that everyone in the team can understand problem that has to be solved<ref>V. Tripathi, A. K. Goyal (2014)</ref>. | Composing acceptance criteria isn't essential only for defining the vision of a product from the customer's perspective. It is also important for team members to achieve good results. It's nothing unusual that different members of the team see a similar issue from various points. Good composed criteria can ensure that everyone in the team can understand problem that has to be solved<ref>V. Tripathi, A. K. Goyal (2014)</ref>. | ||
== How to write good acceptance criteria == | ==How to write good acceptance criteria== | ||
* Good acceptance criteria should be specific, detailed and well defined so that everyone in the team can understand clearly the problem that has to be solved | * Good acceptance criteria should be specific, detailed and well defined so that everyone in the team can understand clearly the problem that has to be solved | ||
* Acceptance criteria should be measurable so that it is possible to estimate project development time | * Acceptance criteria should be measurable so that it is possible to estimate project development time | ||
* They should be agreed by all [[stakeholders]]. External and [[internal stakeholders]] can have different solutions for the same problem. Acceptance criteria should define a consensus between them. | * They should be agreed by all [[stakeholders]]. External and [[internal stakeholders]] can have different solutions for the same problem. Acceptance criteria should define a consensus between them. | ||
== Example of user story with acceptance criteria == | ==Example of user story with acceptance criteria== | ||
'''As''' an authenticated user<br/> | '''As''' an authenticated user<br/> | ||
'''I want to''' be able to set my profile photo<br/> | '''I want to''' be able to set my profile photo<br/> | ||
'''So that''' my profile would be more attractive <br/> | '''So that''' my profile would be more attractive <br/> | ||
'''Given''' the user is logged in and is in | '''Given''' the user is logged in and is in "My profile" section<br/> | ||
'''When''' he presses button | '''When''' he presses button "Change profile photo" and he chooses photo from library <br/> | ||
'''Then''' the [[system]] will upload his photo to server and set his profile photo<ref>M. Kramer, D. Ludlow (2010)</ref>. | '''Then''' the [[system]] will upload his photo to server and set his profile photo<ref>M. Kramer, D. Ludlow (2010)</ref>. | ||
{{infobox5|list1={{i5link|a=[[Advertising brief]]}} — {{i5link|a=[[MoSCoW technique]]}} — {{i5link|a=[[Scope of work]]}} — {{i5link|a=[[Project lifecycle]]}} — {{i5link|a=[[Product backlog]]}} — {{i5link|a=[[Behavior driven development]]}} — {{i5link|a=[[Concept engineering]]}} — {{i5link|a=[[Principles of design harmony]]}} — {{i5link|a=[[Feature-driven development]]}} — {{i5link|a=[[Challenges of international marketing]]}} }} | |||
==References== | ==References== | ||
| Line 55: | Line 38: | ||
* Tripathi V., Goyal A.K. (2014).''[http://ijiset.com/v1s3/IJISET_V1_I3_89.pdf Agile Requirement Engineer : Roles and Responsibilities]''. IJISET - International Journal of Innovative Science, Engineering & Technology, Vol. 1 Issue 3. | * Tripathi V., Goyal A.K. (2014).''[http://ijiset.com/v1s3/IJISET_V1_I3_89.pdf Agile Requirement Engineer : Roles and Responsibilities]''. IJISET - International Journal of Innovative Science, Engineering & Technology, Vol. 1 Issue 3. | ||
== Footnotes == | ==Footnotes== | ||
<references /> | <references /> | ||
{{a| Paulina Baczyńska}} | {{a| Paulina Baczyńska}} | ||
[[Category:Project management]] | [[Category:Project management]] | ||
Latest revision as of 16:09, 17 November 2023
Acceptance criteria are the criteria used in projects or contracts to establish whether job was done properly. Objectives of project or contract can be stated generally and be not precise enough to tell if task was done. For example, objective can state "to build a house with 3 bedrooms". But how large those bedrooms should be? What should be height? Is cellar/basement required? Is kitchen required? What technology should be used to build walls? Therefore, we need acceptance criteria which tell precisely when we agree that the contract/project is done.
In case of agile projects, when we know budget and time span, but we don't know the scope, it is more difficult to define acceptance criteria. Usually criteria are defined as:
- functional criteria - related to specific functions,
- non-functional criteria - related to e.g. layout, look, design,
- performance criteria - related to efficiency.
Acceptance criteria in scrum projects
In scrum, acceptance criteria are integral part of user stories. User stories are simple description of a product function, written from user's perspective.
What we can do to ensure that user stories are finished accurately and conform to a customer's needs? This is the place acceptance criteria become an integral factor. Acceptance criteria are a formalized list of necessities that guarantee that all user stories are finished and all situations are considered. Acceptance criteria determine conditions which ensure that a user story is satisfied. Briefly composed criteria help team members avoid uncertainty about a customer's requests and avoid miscommunication.
Composing acceptance criteria isn't essential only for defining the vision of a product from the customer's perspective. It is also important for team members to achieve good results. It's nothing unusual that different members of the team see a similar issue from various points. Good composed criteria can ensure that everyone in the team can understand problem that has to be solved[1].
How to write good acceptance criteria
- Good acceptance criteria should be specific, detailed and well defined so that everyone in the team can understand clearly the problem that has to be solved
- Acceptance criteria should be measurable so that it is possible to estimate project development time
- They should be agreed by all stakeholders. External and internal stakeholders can have different solutions for the same problem. Acceptance criteria should define a consensus between them.
Example of user story with acceptance criteria
As an authenticated user
I want to be able to set my profile photo
So that my profile would be more attractive
Given the user is logged in and is in "My profile" section
When he presses button "Change profile photo" and he chooses photo from library
Then the system will upload his photo to server and set his profile photo[2].
| Acceptance criteria — recommended articles |
| Advertising brief — MoSCoW technique — Scope of work — Project lifecycle — Product backlog — Behavior driven development — Concept engineering — Principles of design harmony — Feature-driven development — Challenges of international marketing |
References
- Adzic, G. (2011). Specification by example: How successful teams deliver the right software. Shelter Island, NY: Manning.
- El-Dieb, A. S., & Taha, M. R. (2012). Flow characteristics and acceptance criteria of fiber-reinforced self-compacted concrete (FR-SCC). Construction and Building Materials, 27(1), 585-596.
- International Institute of Business Analysis.(2015). A Guide to the Business Analysis Body of Knowledge®. Toronto, ON, CAN: International Institute of Business Analysis.
- Kramer M., Ludlow D.(2010).Domain-specific languages for agile urban policy modelling. Proceedings 27th European Conference on Modelling and Simulation.
- Mahnic V. (2010).Teaching Scrum through Team-Project Work: Students' Perceptions andTeacher's Observations. International Journal of Engineering Education.
- Moertini V. S., Nugroho C. D. (2012).E-commerce mobile marketing model resolving users acceptance criteria. International Journal of Managing Information Technology (IJMIT) Vol.4, No.4.
- Tripathi V., Goyal A.K. (2014).Agile Requirement Engineer : Roles and Responsibilities. IJISET - International Journal of Innovative Science, Engineering & Technology, Vol. 1 Issue 3.
Footnotes
Author: Paulina Baczyńska
