As a methodology, Agile is far from rigorous. There are many Agile schools, flavours, variants and derivatives. As such, definitions for core terms can vary quite a bit, and in significant ways. But if you choose one definition and stick with it, all of this doesn’t matter. Some User Story definitions focus more on “user wants”; others, on benefits and business value. But let’s take a step back and see what a user story is.
User Stories are sentences that describe how the user of a product interacts with it. They also show what they get from that interaction.
A very common format for stories is “As a {{type of user/ persona}} I want to {{perform action/ have ability}} in order to {{goal}}”:
As a: Reader of this blog
I want to: See what other articles have been written on here
In order to: Decide whether these guys can help me
It’s easier if you picture each element of a story as a response to a question. So let’s take them one by one:
User Types – “Who is going to interact with the product?”
It’s easy to neglect User Types. Most analysts will define users by their roles and permissions within the product (“Editor”, “Administrator”, “Reader”). This can produce bland stories that describe HOW a product works, but not WHY it should work that way.
To mitigate this, we use User Personas whenever possible. To us, a simple “Editor” has likes, feels, wants and needs.
Actions & Abilities – “What can users do with the product?”
Our stance on this section is to write “almost features”. We write actions/abilities so that the story is accessible to both a developer and a PR specialist. A tall order, maybe, but it’s an important choice to make.
Atlassian recommends describing what users are “actually trying to achieve”, but in some cases that’s extremely limiting. If your product’s users love visual gimmicks, this approach will generate boring results.
Others prefer feature descriptions, but that can stifle creativity for a designer.
Writing “almost features” feels more natural and allows our clients to write some of the stories themselves (with our aid, of course). This is important, because user stories are supposed to start conversations and lead to common truths (more on what makes these truths acceptable, later).
Goals – “Why would users use the product?”
Because we root our User Types in Personas, goals are very often lifted straight from the personas sheets.
What Goals describe is why an action/ ability is needed. Why the user cares about it. In a way, Goals are the first test case for the product: a story without a goal or with an unclear one is either not necessary or too complicated.
Acceptance Criteria – “How do we know we mean the same thing?”
On their own, User Stories can be deceptive. Consider the following product: a blog with 3 different post templates:
- Text article
- Image gallery
- Recipe
“Template” can mean the following thing:
- PHP template (that the developer cares about)
- Design template (that the designer cares about)
- CMS Page template (that the blogger cares about)
So there is some confusion around a word that’s used by different people to mean different things. And these people need to work together. Now, take the following user story:
As a: Writer on the blog
I want to: change the template of the piece I’m working on
In order to: convey my message better
Should the writer be able to change the PHP code on which the templates are based or switch between templates? Sure, you may argue that “change” is also a vague word, but these things happen. It may be clear enough what the story meant at the time of writing, but 3 months down the line, will everyone involved remember the same thing? Unlikely.
Acceptance Criteria clear up all uncertainties. They are a list of requirements for the user story to be considered properly implemented in the finished product.
We can dispel all confusion related to the story above with one line: “Click on a toggle to switch between templates”. Done. The word “template” can no longer refer to “PHP Template” and “change” has a more precise meaning – “switch”.
Acceptance criteria are more technical than User Stories and are meant to act as constraints on the story, but constraints that are clear for the Client, Project Manager, Developer and QA Tester.
To further increase clarity, our Discovery Process makes extensive use of a file that defines terms that may have ambiguous or multiple meanings for multiple parties or parts of the same product – its name is a bit of a mouthful (Ubiquitous Language Document), but at its core it is a product-specific dictionary.
A huge caveat of all of the above is that they’re abstract and text-based, thus relying too much on a reader’s experience with the Product Development process. To mitigate this and help UX Designers & clients align in regards to what the product should look like, we make heavy use of Wireframes. How we build them and why they’re indispensable makes the subject of another article (coming soon).
