User Stories, Acceptance Criteria and Acceptance Tests
User Story Syntax
- "As a <role>, I want <goal/desire> [so that <benefit>]"
Valuable
A user story must deliver value to the end user
User Story
An Agile requirement, stated as a sentence or two of plain English Often expressed from the user's point of view, and describes a unit of desired functionality Used as the basis for defining the functions a business system must provide Captures the 'who,' 'what,' and 'why' of a requirement in a simple, concise way Define what has to be built in the software project Prioritized by the customer (or the product owner) to indicate which are most important for the system When user stories are about to be implemented, the developers should be able to talk to the customer - Short stories may be difficult to interpret, may require some background knowledge or the requirements may have changed since the story was written Every user story must at some point have one or more acceptance tests, allowing the developer to test when the user story is done
Sprint Backlog
As a ____, I want to be able to ____ so that____ I will know this is done when____ (Possible automation of the acceptance test) To do this I must: 1. ____ 2. ____ Development team breaks out the detail of work needed to pass test
Product Backlog
As a ____, I want to be able to ____ so that____ Might have an initial estimate (perhaps for both analysis and development), and an expression of technical and business confidence that this is real and achievable
Release Backlog
As a ____, I want to be able to ____ so that____ I will know this is done when____ More detailed estimate, and a specific acceptance test - low confidence stories might be "spiked" or prototyped
Acceptance Testing Benefits
Encourage closer collaboration between developers on the one hand and customers, users or domain experts on the other Provide a clear and unambiguous "contract" between customers and developers − A product which passes acceptance tests will be considered adequate (though customers and developers might refine existing tests or suggest new ones as necessary) • Decrease the chance and severity both of new defects and regressions
User Story Creation - Conversation
Exchange of thoughts, opinions, and feelings Takes place over time, particularly when the story is estimated Conversations also occur at the iteration planning meeting when the story is scheduled for implementation Supplement with documents as needed
User Story Benefits
Mitigating the risks of delayed feedback For the customer or product owner, the option to change their mind on the details or the schedule priority of any user story not yet implemented For developers, being given clear and precise acceptance criteria, and ongoing feedback as they complete work •Promoting a clear separation of responsibilities between defining the "what" (province of the customer or product owner) and the "how" (province of the technical team)
Acceptance Test
Refers to the functional testing of a user story by the agile team The customer specifies scenarios to test when a user story has been correctly implemented A story can have one or many acceptance tests, whatever it takes to ensure the functionality works Acceptance tests are black-box tests Each acceptance test represents some expected result from the system Acceptance tests are also used as regression tests prior to a production release A user story is not considered complete until it has passed its acceptance tests − This means that new acceptance tests must be created for each iteration or the development team will report zero progress
User Story Creation - Confirmation
Story tests are acceptance tests for the product owner Product owner specifies the story tests but will collaborate with team to create them Team can add additional tests
Acceptance Criteria Syntax
The Given-When-Then formula is a template intended to guide the writing of acceptance tests for a User Story User Story Template: − As a [user role] − I want to [desired feature] − So that [value/benefit] Acceptance Criteria: − Given (the starting point/initial state) − When (action) − Then (outcome)
Acceptance Criteria
The conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system A set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level Constitute our "Definition of Done" Doneness - A team's universally agreed-upon criteria for what makes a unit of work "potentially shippable"
Independent
The user story should be self-contained, in a way that there is no inherent dependency on another user story
Small
User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty
Negotiable
User stories, up until they are part of an iteration, can always be changed and rewritten
Estimable
You must always be able to estimate the size of a user story
Card
a physical token giving tangible and durable form to what would only be an abstraction
Conversation
takes place at different times and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.)
Confirmation
the more formal the better; ensures that the objectives the conversation revolved around have been finally reached
Testable
the user story or its related description must provide the necessary information to make test development possible
Common User Story Mistakes
• No Business Value or Benefit for Customer • No Acceptance Criteria or Conditions of Satisfaction • User Story for Developer • Example: "As a developer I want to replaced the folder widget, so that I have maintained folder widget." - This typical example of Story for a Technical Backlog or Technical Requirement representation - They have the right to be implemented, but they do not represent value for the customer and you will not get a buy-in from Product Owner - You should rewrite it from a user point of view