Introduction

Acceptance Criteria are a list of goals that a solution must meet for it to be considered fit for purpose.

The Acceptance Criteria should be created in consultation with all stakeholders, and signed off before development starts. On occasion, time constraints may require development to start before these are signed off. This is only acceptable if all the stakeholders have contributed to generating them, and at least verbally agreement has been reached.

By having the Acceptance Criteria documented and signed off before development begins, it means that the implementation has a set target. This allows test cases to be written, which prove the Acceptance Criteria have been met, which in turn allows the engineers to prove they have developed what has been requested.

Raising Issues against Acceptance Criteria

If an Issue with the Acceptance Criteria is identified during the development phase, the current sprint/iteration should be allowed to finish.  The Feature can be demonstrated to the stakeholders, and if it is not working as intended, with agreement of all stakeholders, a change request should be raised to document the change of requirements, and the Acceptance Criteria can be updated to reflect the new requirements.

Stopping prior to finishing a sprint/iteration is a common mistake that is often made at this point.  However, doing so should be avoided for several reasons.

• Acceptance Criteria are signed off and agreed by all the stakeholders.  By finishing development of a complete Feature, any Issue arising with the Acceptance Criteria may be resolved and it no longer require addressing.
• If a Feature does require changing, then it needs all the stake holder to agree the change. Disagreements can arise over the correct Acceptance Criteria.  However, having something working facilitates further discussion, while allowing further development to proceed unimpeded.

Structure

Within Azure Dev Ops, Acceptance Criteria are stored within a User Story. This allows easy reporting on User Stories and their Acceptance Criteria

Instructions

#	Steps	Image
01	Ensure User Stories are created based on design
02	For each User Story, review and add draft Acceptance Criteria in Azure Dev Ops. A numbered list should be used to create them.  This allows the test cases to reference the Acceptance Criteria that they are testing.
03	Once the draft Acceptance Criteria has been created, a meeting should be setup with the key stakeholders who will sign them off. The stakeholders can be given the stakeholder permission in Azure Dev Ops so they can view them before the meeting.
04	During the meeting, Each user story that is being developed during this sprint/iteration is reviewed to confirm it is scope, and the Acceptance Criteria reviewed.  Edits and tweaks should be made based on the feedback in the room.
05	Once the meeting is complete, the User Acceptance Criteria Sign off document should be produced, and sent out to the stakeholders to sign off. Click Queries in Azure Dev Ops to start the process to export the data.
05.1	Click New Query
05.2	Edit the Query Work Item Type = User Story Iteration Path = Current Spring
05.3	You can click Run Query to review the output
05.5	Click Column Options
05.5	Select ID, Title, and Acceptance Criteria, and click Ok, before clicking Save
06	With the query now saved, you can call it Current User Stories and Acceptance Criteria and it can be saved as a shared Query
06.1	Click on Results
06.2	Holding Ctrl, select all of the User Stories
06.3	Right click, and select Copy as HTML
06.4	It can now be pasted into an Acceptance Sign Off Word Document
06.5	The formatting on the Acceptance Criteria will be lost, but can be quickly edited back in.
07	The document can now be sent out to the stakeholders for it to be signed off. Once it is signed off, test cases can then start being created.