Page History
...
Table of Contents |
---|
Overview
In Agile Methodologies, Acceptance criteria Criteria (AC) are used to define when a given user story can be "accepted" by some relevant stakeholder.
...
The criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. - ISTQB GlossaryAC are very useful for the team as they
Acceptance Criteria:
- clarify some aspects of the underlying story that are relevant to someone
...
- ;
...
- can be checked and validated by testing; they should be clear enough so that clear accept/don't accept decision can be taken.
But the following question arises: How can we know whether a certain criterion has been checked or validated by testing?
Before diving into it, we need to be aware of typical patterns teams follow for handling AC.
Info | ||
---|---|---|
| ||
Please note that by "acceptingAccepting" the story , it doesn't mean the story it is bug free or that acceptance criteria should describe all possible usage scenarios about the story; it's only a way to clarify some usage rules that are important for some stakeholders and that the user story "can work". A common misconception is about "done" vs "acceptance criteria". Acceptance criteria are user story specific, while the definition of done applies to all product increments/user stories. Therefore the fact that acceptance criteria has been met, doesn't mean it can be considered "done" and thus ready to be shipped. |
...
This is an unstructured approach that inhibits full traceability between story<=>AC<=>tests<=>test runs<=>defects.
Some teams may decide to use a specific custom field for this purpose or even to use specific Jira apps/plugins to clearly manage AC; however, these usually don't have unique IDs that can be referred elsewhere.
...
- create an issue type named "Acceptance Criterion" or equivalent. Go to Jira Settings > Issues > Issue Types.
- add that issue type to the issue type scheme used by your Jira project
- define in Xray settings, the sub-requirement (e.g. the "Acceptance Criterion" issue) to be handled as a coverable issue (i.e. by adding it to the "Requirement Issue Types" column)
- define in Xray settings, the relation between the parent requirement (e.g. the "Story" issue) and the sub-requirement (e.g. the "Acceptance Criterion" issue)
- Note: if you want to define this relation based on a custom issue link type (e.g., you could create a "Satisfy: satisfies/is satisfied by"), then you need to create first
- Note: if you want to define this relation based on a custom issue link type (e.g., you could create a "Satisfy: satisfies/is satisfied by"), then you need to create first
...
Info | ||
---|---|---|
| ||
In Xray, sub-requirements can be identified and related to parent requirements using:
Using sub-tasks may allow further control over the progress of the parent issue (e.g. the Story), such as giving the ability to restrict closing it or not. However, usage of "sub-tasks", namely for this purpose, is something that has to be evaluated in your specific context. To use sub-tasks:
|
...