gaspersic/freeCodeCamp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Further explanation of What vs How (#24135)

Browse Source
This commit is contained in:
DaddyBA
2019-03-15 04:08:05 -05:00
committed by Manish Giri
parent 0bf01ae15f
commit f1360f1fa7
1 changed files with 18 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
guide/english/agile/acceptance-criteria/index.md
View File

@@ -4,12 +4,26 @@ title: Acceptance Criteria
## Acceptance Criteria
The User Story, as an item in your backlog, is a placeholder for a conversation. In this conversation,
the Product Owner and the Delivery Team reach an understanding on the desired outcome.
the Product Owner and the Delivery Team reach a shared understanding of **"Who"** wants the change, **"What"** they need to be able to do (in business terms, not 'clicks' and boxes, etc.) and **"Why"** they want it.
The Acceptance Criteria tells the Delivery Team how the code should behave. Avoid writing the **"How"** of the User Story; keep to the **"What"**.
If the team is following Test Driven Development (TDD), it may provide the framework for the automated tests.
Acceptance Criteria tells the Delivery Team how the code should behave. Avoid writing the **"How"** of the User Story, keep to the **"What"**.
An example might be:
- "Given a record needs to be reviewed,
- When the user approves the record,
- Then the status changes to reflect the decision made by the user."
In contrast:
- "Given the record has a staus code of 2 which means it needs reviewed
- When the user marks the checkbox with the label 'I approve this change'
- Then the database field of need review gets set to false and the field of approved gets set to true and the screen displays that the record is approved and an email is sent to Bill letting him know that June approved the record."
The second example is describing to solution, whereas the first example is more focused on what are the needs, not how those needs will be met by the solution.
If the team is following Test Driven Development (TDD), Acceptance Criteria may provide the framework for the automated tests.
The Acceptance Criteria will be the beginning of the test plan for the QA team. It is what is required for the story to go live, the QA team may still apply exploratory testing to pick up potential defects. Regardless of the team's test methodology, it should have a pass-fail definition of what it means to complete this increment of work.
The Acceptance Criteria will be the beginning of the test plan for the QA team. The Acceptance Criteria is what is required for the story to go live, the QA team may still apply exploratory testing to pick up potential defects.
Most importantly, if the story does not meet each of the Acceptance Criteria, then the Product Owner should not be accepting the story at the end of the iteration.
@@ -19,7 +33,6 @@ Acceptance criteria can be viewed as an instrument to protect the Delivery Team.
Consider the following situation: when accepting the user story the Product Owner suggests adding something that was not in the scope of the User story. In this case the Delivery team is in the position to reject this request (however small it might be) and ask the Product owner to create a new User Story that can be taken care of in another Sprint.
#### More Information
Nomad8 provides a [FAQ on Acceptance Criteria](https://nomad8.com/acceptance_criteria/)