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