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

used "beginning" in place of "beginnings" and added a letter "a" (#24319)

Browse Source
This commit is contained in:
Deepanshu Maheshwari
2018-12-08 11:56:07 +05:30
committed by Manish Giri
parent 8607451546
commit d200f83f27
1 changed files with 4 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -8,11 +8,13 @@ the Product Owner and the Delivery Team reach an understanding on the desired ou
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.
The Acceptance Criteria will be the beginnings 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.
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.
Acceptance criteria can be viewed as an instrument to protect the Delivery Team. When the Delivery Team commits to a fixed set of stories in the Sprint planning, they commit to fixed set of acceptance criteria as well. This helps to avoid scope creep.
Acceptance criteria can be viewed as an instrument to protect the Delivery Team. When the Delivery Team commits to a fixed set of stories in the Sprint planning they commit to a fixed set of acceptance criteria as well. This helps to avoid scope creep.
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.