Currently set to No Index
Currently set to No Follow

Anatomy of a User Story

Basic

difficulty

Stage 1-3

Agile IQ® Level

Backlog Items

Artefact

Introduction

While it’s easy to write “as a user”, there are many more parts to a great User Story, including:

  • Acceptance Criteria
  • High level solutions and designs
  • Sketches and diagrams
  • Wireframes
  • Developer notes

The Basics

Identify:

  • The user. If you use Personas, insert the Persona.
  • The user’s problem that needs solving.
  • The reason the user needs a solution.
user story format 01

Watch out for

The “User” in the User Story is a person, end user, customer or persona. It’s not:

  • You.
  • Your team.
  • Your organisation.
  • An IT system or component.
  • An application.

Don’t use the User Story format when:

  • There is no user. This is a system interaction only.
  • The item is for the organisation.
  • When the work is for the team. E.g. you don’t write “as a team member”.

In these cases, use other formats like:

  • I.N.V.E.S.T.
  • Three Cs – Card. Conversation. Confirmation.

Acceptance criteria

There is often a preference for how features will work. This is often based on business rules, compliance needs, or process-driven requirements. These are often written as “acceptance criteria”.

Write the acceptance criteria as bullet points

  • Must not use an invalid credit card number
  • Must not use an expired credit card
  • Must include the CCV / security code
  • Must apply 5% surcharge

Date-driven criteria

If the item needs to be delivered by a specific date, write the date and any related rationale as part of the acceptance criteria.

Behaviour-driven criteria

When there is a workflow or user experience that is expected of the User Story, write a this as acceptance criteria. GIVEN/WHEN/THEN format is useful pattern to use.

GIVEN I’ve got items in my shopping card

AND I get to the payment area

WHEN I enter the data

THEN it validates the credit card information

AND THEN I receive a message indicating the information is correct before it asks me to submit the data

 

anatomy of a user story agile iq 01

Benefits of Given, When, Then

Some of the benefits of using this approach:

  • Natural language is easier for a broader range of stakeholders to understand
  • Increases communication amongst team members
  • You define behaviours rather than tests
  • Provides visible results
  • Forces separation of pre-conditions and post-conditions
  • Tests focus on one scenario so troubleshooting is easier
  • Opportunities to automate code directly from BDD test definitions

When dealing with software development, many programming tools such as Cucumber and JBehave provide test features that accommodate tests defined in the Given-When-Then format. Though this is the case, the approach to testing business requirements is not limited to software products.

Estimation

An estimation for each User Story provides the Product Owner with important information on:

  • How large the item is
  • Whether it will fit into a Sprint or not
  • The size will relate how much budget needs to be spent to deliver the item
  • Why the item is needed and by whom

Estimate the size of the work needed for the whole team to deliver to meet the Definition of Done. 

anatomy of a user story agile iq 02

Watch Out For

  • Be careful not to write overly-complicated test statements. It may be better to split out into multiple tests.
  • Update the “Definition of Ready” such that quality requirements are testable using the Given-When-Then format before teams start working on Product Backlog Items.

References

1. Manifesto for Agile Software Development. https://agilemanifesto.org

2. TDD. https://www.agilealliance.org/glossary/tdd/

3. Behaviour Driven Development (BDD). https://www.agilealliance.org/glossary/bdd/

4. Fowler, M. (2013) Given When Then. https://martinfowler.com/bliki/GivenWhenThen.html

search previous next tag category expand menu location phone mail time cart zoom edit close