There are lots of UX practitioners out there who are still resistant to Agile methodologies. One of the most common negatives we hear is aimed at agile user stories. User stories are short descriptions of a feature from the point of view of the user who wants it, usually a customer. They’re often written like a logic equation; As a < type of user >, I want <activity>.
The criticism goes that agile user stories are not user-centric, because they describe untrue situations – stories where users want to do something that users would never actually do. This makes user stories useless – worse than useless in fact because they can actually cause poor design through misrepresentation.
Truth is, we used to be down on user stories too, for these very reasons. We only became converts after we collaborated with a team who were using them properly. It became clear that we hadn’t got a problem with the existence of a user story; we had a problem with user stories being done badly.
These are the 7 deadly sins that make user stories useless, and what to do instead.
User stories are often written as a simple sentence, formatted as:
As a < type of user >, I want <activity>.
For example, As a theatre customer, I want to open the ticket booking calendar.
But this syntax is incomplete because it leaves out a crucial element of any story; motivation. It doesn’t tell us why the user wants to do this activity. Without this information, the story doesn’t make sense in a wider context. Instead, a better syntax would be;
As a < type of user >, I <verb> < activity > so that < some reason >.
As a theatre customer, I want to look at the booking calendar so that I can find the best seats at the best price.
“So that” is the most important part of the story sentence here, as it explains the motivation for completing the task. This wider context helps developers understand where this small story fits into the grand scheme of things.
It’s also well worth remembering that your user may not ‘want’ something at all. They might ‘expect’ something:
As a theatre customer, I expect to receive a confirmation of my order so that I know it’s gone through OK.
They might ‘hope’ or ‘accept’ something:
As a theatre customer, I accept that I have to tick the terms and conditions box so that I can complete my purchase.
It’s important to use the most relevant verb in a user story based on your understanding of user motivations.
Some UX teams make the mistake of writing user stories from a purely functional perspective, in terms of the mechanics of a design rather than what a user wants. For example, a false user story would be:
As an online academy student, I want to press the blue button to submit the form and progress to the next screen.
But the user doesn’t care about what blue button does. They don’t care about the minutia of how they achieve their goal; all they care about is the goal itself. A true version of that story might be:
As an online academy student, I want to submit my work so that it can be assessed.
The false user story here focuses on the graphical interface, not the user. Describing graphical user interface behaviour in words is pointless because those words will be interpreted in a different way depending on the person. Instead, it’s better to use a wireframe or a prototype to remove any ambiguity about the interface.
Acceptance criteria, or your ‘definition of done’, are a key part of the agile process. Without them, you can’t know that your end product actually meets the requirements it needs to. Does it fulfil user expectations and stakeholder requirements?
But adding acceptance criteria into user stories can be clumsy and make the story convoluted, or involve describing things a user wouldn’t do or expect. The result is that teams often just forget or ignore acceptance criteria. One UX practitioner told us they were accused of “not being agile” for suggesting their team capture acceptance criteria.
But the agile manifesto states that while working software should be valued above comprehensive documentation, documentation still has value. We’re not advocating the 700-page specification documents of the past (definitely not!) but a few quick bullet points to make sure everyone is aware of what the story should achieve when implemented are crucial.
Acceptance criteria should always state a user’s intent, but not the solution. Bad criteria might read:
The user can click a checkbox to approve an invoice.
The user doesn’t care about clicking the checkbox, they only care about approving invoices. The Given/When/Then format is helpful way to specify criteria:
Given (some precondition) when (I do some action) then (I expect some result).
Given that I am authorised to make payments, when I open an invoice then I expect to be able to authorise or reject it.
The criteria should be independent of the implementation, and discuss WHAT to expect, and not HOW to implement the functionality.
Some UX teams write all their user stories from the point of view of their end customer, but this results in some nonsensical stories. For example:
As a customer, I want to read the terms and conditions so I understand my consumer rights.
This is clearly a false story; whoever wants to read the T&C? No one. Instead, this story should be written from the point of view of the person who requires users to read the terms and conditions.
As Head of Legal, I need users to read and accept the terms and conditions, so that we comply with our obligations.
A user story should help your team see the overall picture of what they’re working towards, helping them to build the right thing. But when teams ignore this bigger picture, concentrating on specific user stories instead of using stories to map a whole customer journey to see how all features fit together, they’re like the proverbial blind men describing an elephant; each knowing only a small part and so creating an incoherent whole. They risk building something that doesn’t fulfil their customers’ needs and expectations.
User stories should be scenes in a bigger narrative, a coherent user experience that incorporates smaller stories.
Not everything works as a user story, but some teams use them everywhere. For example, describing validation experiments as a user story is unlikely to be useful. Instead, a good format for doing this is as a hypothesis:
We believe that <doing something> for <type of user> will result in <outcome>. We’ll know this is true when we see <measurable change>.
We believe that building a support chatbot for existing customers will result in fewer calls to support. We’ll know this is true when we see call volume drop.
Along the same lines, agile design can also include “Tasks”, typically things like “code this”, “design that”, “create test data for such-and-such”, “automate that”. These tend to be things done by one person, and they work better in this format than as user stories.
Because many UX practitioners have written off user stories as “not user-centric” or “just for developers”, they fail to make time to get involved in creating them, leaving it to someone else in the process. But helping write the user stories is the best way to ensure that all of your meticulous UX design and research sees the light of day.
Best-case scenario, if you don’t get involved in user stories, is that you’ll get to review development as it progresses. But the problem is, you’ll inevitably want to make changes and there will be a limited amount of time to make them. It’s more effective to take the opportunity to get as much as possible built right the first time. That leaves spare capacity to deliver something exceptional.