User Stories

Introduction

A user story provides a simple, clear narrative about a requirement in terms of what’s needed, for who and why. The focus is on features that’ll support the business vision and add real value for real people with real needs.

User Stories are used throughout the Agile Lifecycle, helping to define the high-level objectives of a project, all the way down to the individual requirements of the target system.

They’ve been introduced to overcome deficiencies with traditional business requirements, where their simplicity, lack of ambiguity and focus on need (rather than the solution) greatly assist their understanding by a wide audience of business and solutions people.

The Four Cs

User Stories comprise four elements, known as “The Four Cs” – being The Card, The Conversation, The Confirmation, and The Context.

1. The Card

Each User Story is captured on the front of a 15x10 cm card (or its digital equivalent), using the following format:

• As a… (the who)
• I want to… (the what)
• So that… (the why)

The idea of using such a small card is to limit the amount of detail, thereby creating the need for richer communication between the requesters and implementers of a User Story.

As an example, here’s a User Story for a high-level project objective (known as an “Epic”):

• As the Head of HR
• I want to simplify the new joiner procedure
• So that successful candidates are onboarded more efficiently.

And here’s one for a feature of the target system:

• As a Payroll Manager
• I want to receive an alert to set up a new joiner on the payroll
• So that their first month’s salary is paid on time.

Acceptance criteria should be listed on the reverse of the card to indicate the things that need to be satisfied for the User Story to be recognised as complete (“Done”).

2. The Conversation

This is about taking steps to stimulate dialogue and collaboration between stakeholders, in order to develop a shared understanding of what’s needed for each User Story, while providing just enough detail to allow it to be taken to the next stage.

3. The Confirmation

These are the rules for agreeing that a User Story is Done, such as with the satisfaction of all the acceptance criteria and formal acceptance by the owner of the solution.

4. The Context

This provides a richer understanding of a User Story, plus insight as to how it relates to other Stories.

This can assist decisions about the order in which the User Stories are addressed and how they might be bundled with others within a Timebox or Increment.

The team often uses facilitated workshops to progress each of the Four Cs.

User Stories throughout the Agile Lifecycle

1. During the Feasability Phase

This phase aims to decide whether the project is viable from a business and technical perspective. 

At this stage, Epics are created to capture the top-level business objectives and goals – with a maximum of ten Epics being written as statements, using the User Story format.

2. During the Foundations Phase

This phase aims to establish a firm and enduring foundation for the project. 

User Stories about requirements are written at a high level (along with their acceptance criteria) to serve as placeholders for consideration in a subsequent Delivery phase.

User Stories for Non-Functional Requirements – covering things like security, availability, performance, certification and compliance – should also be created, given that they might constrain later design decisions.

All of these User Stories will be used to clarify scope, priorities and estimates.

A Prioritised Requirements List (“PRL” or “Backlog”) will also be assembled in this phase to keep a record of all the User Stories, including their priorities and requesters.

The version of the PRL that emerges at the end of Foundations can be used as a fixed reference point (“Baseline”) to help manage scope creep.

3. During the Delivery Phase

These are the rules for agreeing that a User Story is Done, such as with the satisfaction of all the acceptance criteria and formal acceptance by the owner of the solution.

The Delivery phase of the project will consist of a number of fixed-period (typically 2-4 week) Timeboxes (or “Sprints”), during which an agreed list of User Stories will be worked on.

It’s at this stage that the lower-level detail of the User Stories will be discussed, along with the acceptance criteria. Considering the detail now will allow for greater accuracy and relevance to the emerging solution.

This exercise might conclude that a User Story should be broken down (“decomposed”) into two or more smaller Stories that could have different priorities and/or be left for later Timeboxes.

Testing is carried out throughout the Timebox to determine whether each User Story has been completed by reference to its acceptance criteria.

If a User Story is deemed incomplete at the end of the Timebox, then a decision needs to be made about moving it to a subsequent Timebox, or leaving it for now.

Managing User Stories

1. During the Feasibility Phase

The "INVEST Checklist" should be used to help improve the quality of User Stories:

It’s usually the job of a Business Analyst to quality check the User Stories and to make the necessary change

• Independent — a User Story must be independent of others, evidenced by the fact that it can be moved around with minimal impact on other Stories. If this isn’t the case, some of the dependent ones might be combined into a single User Story.
• Negotiable — User Stories are placeholders for requirements, not binding commitments. In some cases they may be dropped, given their relative priority to other User Stories and a lack of time.
• Valuable — User Stories should represent features that have clear business value to a user or owner of the solution, and the Stories must be written in a way that these people can understand.
• Estimatable — User Stories should be clear enough that they can be estimated.
• Small enough — The User Stories that are to be taken forward in the Delivery phase need to be small enough to be delivered in one Timebox, with larger User Stories being broken down into smaller ones.
• Testable — the wording of User Stories and their acceptance criteria should remove any doubt about the type of testing required to prove that the Stories are Done.

2. Prioritisation and challenge

The relative importance of each User Story should be noted by way of their priority, with MoSCoW Prioritisation being a favoured technique.

It’s essential that the higher priorities can be justified, and it’s usually the job of the Project Manager or Business Analyst to challenge the Business Representatives about this.

When new requirements emerge after a project has started, they should be investigated by the Business Analyst to see whether they represent additional detail for existing User Stories.

If that’s the case, then the User Story and PRL might be updated for this; whereas those that broaden the scope of the solution should be escalated to the Business Representatives for a decision about their inclusion and priority, and whether other User Stories should be relegated to make way for them.

3. Maintaining the PRL

The PRL must be updated regularly to:

• Capture new User Stories
• Add detail to existing User Stories
• Show changed priorities
• Record the progress that's been made
• Mark a User Story as Done

The Project Manager and Business Analyst often share responsibility for maintaining the PRL.

Tracking Progress

There must be a high degree of visibility throughout an agile project, and the following tools and techniques can be used for keeping track of User Stories once the project is in flight

1. Story Maps

These are used to record the User Story hierarchy, showing the association between the Epics and the underlying User Stories.

Story Maps can be used to plan and for checking that User Stories have been assigned to the right Epic.

2. The PRL

The PRL must be updated regularly and made accessible to all

3. Story Boards

Once a Timebox is underway, the constituent User Stories are moved around the Story Board to reflect their status: To Do, Ready to Develop, In Progress, Ready for Sign Off, and Done

4. Stand-Ups

These meetings usually take place on a daily basis for individual members of the delivery team to comment on:

• What they've done for any of the User Stories since the previous Stand-Up.
• What they'll do in the period until the next Stand-Up
• Whether they're experiencing any issues ("Blockers") that might require the assistance of others.

Business Representatives must be able to attend these sessions as observers.

Author

Agile Business Consortium

The Agile Business Consortium is the professional body for business agility. We’re all about community – whether you’re a multinational working through a large-scale transformation, a new start-up, or a contractor, we can support you to achieve more, to grow more, and to build your business agility. As a global not-for-profit organisation that’s been around for over 25 years, our knowledge and experience around agile competencies and behaviours can offer you the guidance you need to reach your agility goals. Together with our partners, we create and share agile research, case studies, resources and tools that help you compete in today’s uncertain world. A registered not-for-profit, we’re the world’s longest-standing agile-orientated organisation. We’re the brains behind AgilePM®, AgileBA®, AgilePgM®, AgilePfM™ and AgileDS™. Based in the UK, we have members in over 30 countries around the world.

Email:

[email protected]

Phone:

+44 01233611162

Twitter:

@Agile_Biz

Website:

agilebusiness.org

LinkedIn:

https://linkedin.com/company/agile-business-consortium