User Scenarios and Acceptance Tests in Agile
In this article we will explain what are User Scenarios (US) and Acceptance Tests (AT), what is their value and what are the general rules and requirements of writing them.
What are User Scenario and Acceptance Tests?
User Scenarios and Acceptance Tests are detailed requirements for the software development team to plan what and how they will build the needed solution. As a general rule, they should be understandable to nontechnical people in the business. The technical team uses the US and ATs as the source of information to define their tasks in order to deliver the expected output of each user scenario and acceptance test.
The consistent pattern should be used for writing the requirements to improve understanding and communication of what is needed and how it will be tested. Writing User Scenarios and Acceptance Tests distils, crystallizes, and clarifies thought and helps break complex solutions into simpler parts.
The technical experts can then use the User Scenarios and Acceptance Tests to determine the best way to build what has been asked for.
As a (role) I want/need (ability/feature ) so that (benefit).
Use either of the two patterns below to describe each test.
As a (role) I will (specify the action/event ) to confirm that (Ability/feature ) does the following (expected outcome).
Given (one scenario and related conditions) when (specify the action/event ) then (expected outcome).
When do we gather information and write up the User Scenario and Acceptance Tests?
The information for the US and AT is gathered through the discovery process at the beginning of the software development project and then documented in the design process. You may also use the concept of rolling wave planning, where you also write-up and refine US and AT before sprints or at the end of management stages. This enables you to leverage the knowledge gained during the build process to update and improve user scenarios and acceptance tests.
- Small (preferably less that 5 days to develop)
What does a well-formed US and AT do?
- Define a unit of work that can be added to a sprint backlog / work package for each sprint or iteration
- Communicates at a detail level what the person ordering the functionality/behaviour wants
- Communicates how the developed functionality/behaviour will be tested for acceptance
- Use a standard pattern to give structure and completeness
- Explicitly state quality expectations
- Define and understand what the term “Done” means for each User Scenario and Acceptance Test.