All about user stories

It’s fair to say that as business analysts, most of us are among user stories for a good proportion of our day. Do we know what they are, how they are used, what they are not? Be honest. Read on to learn all about user stories (well, let’s make a start at least). We’ll look at a few user story myths along the way.

The BABOK defines user stories as below (10.48 User Stories):

A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.

It then describes user stories as:

User stories capture the needs of a specific stakeholder and enable teams to define features of value to a stakeholder using short, simple documentation.

Furthermore, the Agile Extension to the BABOK Guide (Agile Extension) defines user stories as:

User Stories are used to convey a customer requirement for the delivery team.

Type of requirement

However you look at it, user stories are quite clearly a stakeholder requirement as discussed in Requirements 101 – Part 1. The user story represents a stakeholder need – it says so on the tin!

Myth: User stories are solution (functional) requirements
Reality: User stories are stakeholder requirements

Elements of a user story

I like to use the following parts of a user story:

• Title (or story name): a short descriptor of the story
• Story: As a [persona], I want [what], so that [why]
• Acceptance criteria: usually these AC must exist for the story to enter development (should be specified in your team’s Definition of Ready), and must pass for the story to be considered ‘done’ (this should be specified in your Definition of Done)
• Estimate: points, T-shirt sizes, days, whatever makes sense for your team

There is not an ‘official’ way of writing user stories, use whatever your team agrees on. The above elements are quite standard and should be uncontroversial.

Example user story

Title: Query balance
Story: As a savings account holder, I want to query my account balance at the ATM, so that I know how much money I have in my account.
AC1: Given the customer holds a savings account, when the savings account balance is requested, the savings account balance is displayed.
AC2: Given the customer does not hold a savings account, when the savings account balance is requested, an error message is displayed.
AC3: (and so on…)
Estimate: L (Large)

Acceptance criteria

Acceptance criteria (AC) serve many functions. Primarily they serve to define test conditions for the story to pass. However they also can serve as the main mechanism to define solution (functional) requirements. Establishing boundaries of how the solution will perform effectively defines what it will do. In the example above, the acceptance criteria can define behaviours of the solution such as the nature and format of the balance and error messages, how the solution will respond after the customer requests the balance, and so on.

AC also help the team to reach a shared understanding about the nature of the story. If it’s well understood, it can be delivered.

Acceptance criteria format

AC can be written in any format that works for the team. However, the format below is a common one and enforces some structure to your AC.

Given [some scenario],
when [some trigger],
then [expected result].

This format works well for testers as much of the work necessary to think about and configure test scenarios is done by writing the acceptance criteria.

The Three Amigos

How do user stories get written and elaborated? A common approach is to use the Three Amigos approach. The Three Amigos is a representation of three perspectives that must be considered when thinking about user stories:

• Business: ensure the user story accurately captures the essence of what is trying to be achieved
• Development: provide input as to how the story might be delivered
• Testing: provide input as to how the story might be tested

Each of those perspectives may have input about how the story is written (does it meet the INVEST criteria of quality user stories), is it clear enough to be built/coded/delivered, and is it clear enough to be testable and have all the test scenarios been covered? The business analyst may get involved as a proxy for the business/product owner, or for the development or testing roles. Or, if your team has all three roles available, the BA may facilitate Three Amigos sessions for consistency and repeatability.

Myth: user stories are written by the technical team
Reality: all three perspectives need to be considered when writing and elaborating a user story

This is a particularly pervasive and dangerous myth – it perpetuates the terrible idea that development is something that developers do in isolation and that development is a means unto itself. I was once told by a client with a very straight face that if I got involved with writing user stories the technical team would be ‘very upset’.

The 3 Cs

The 3 Cs is a mnemonic to help you remember the components of a user story.

• Card: an index card or Post-It if your team uses physical stories, or a virtual card in Jira, DevOps or similar. A ‘thing’ that can be moved around, prioritised, estimated, discussed, discarded and otherwise manipulated.
• Conversation: a user story is not a fully self-contained collection of specifications. It is the promise of a future conversation, i.e. by writing the story, the team commits to coming back to it later to have a conversation about what it means, how it behaves, how big it is, how it can be tested, is it valuable, what its priority is, and more
• Confirmation: verification (once ‘Done’) that the story has delivered the intended value

Myth: a user story is a specification for the developers
Reality: a user story initially is a promise of a future conversation, it is not a ‘contract for features‘

Supporting information

Clearly not all the information required to develop a story, test it, and document it for operations can fit onto a 6×4 index card or virtual equivalent. Think about things such as an ER diagram and database schema, API interface and contract, a data dictionary, wireframes, prototypes and colour palettes – these all need to be used and referenced when delivering a user story. This supporting information might be required for the story to be considered ‘Ready’, or it might be required for the story to be considered ‘Done’. If your organisation needs architecture designs, administrator guides, user manuals, help desk scripts and other material – specify it in your ‘Definition of Done’. It’s not all about coding!

Myth: agile doesn’t need documentation
Reality: specify the documentation required in your ‘Definition of Done’

Wrapping up (for now)

That covers a lot of ground for user stories and is a good introduction to some basics. We’ve covered requirement type, elements, acceptance criteria, Three Amigos, 3 Cs, supporting information and busted many myths along the way.