Anatomy of a Great User Story

How to tell your product’s tale

A user story is, get this, a story about your user.

These artifacts serve as an account of how your user should ultimately experience the product that you’ve determined you need to build. They are typically the artifact that product managers develop in their roles of asking for particular user experiences from their engineering teams.

Great user stories are best treated as reminders of conversations that have occurred amongst a product team. You’ve gotten in a room together to discuss a user and their needs, and you’ve determined through extensive testing that one particular unit of functionality is going to make a positive impact, given some predefined and well-understood goals for your project.

Great user stories might include:

• A Title that describes what a user needs in order to solve their problem
• Any relevant Wireframes
• Acceptance Criteria that have been negotiated with the engineering team

Before the story, the user

Your job as the product manager is to change the world. That might seem daunting, but if we understand exactly who the different users in our market are, and what needs they have, we can change the world from one user’s perspective at a time.

A User Persona is one common way to tell a user’s story. They describe a user’s characteristics, and goals, and they can provide a limited window into the characteristics that differentiate that user from others. They are limited though, in that there’s only so much knowledge that we can share in the limited space that any single piece of documentation can afford us.

If you want to tell a story about someone, you’d best know a lot about them. This understanding is built on extensive conversations and research, for which no documentation will fully replace.

The more we as product managers can expose our teams to real users in pain, the more motivated they will be to build great products, and the more information they’ll have as to how to resolve that pain.

Once you have that prerequisite understanding, you’re ready to start telling a story about your product.

A Title

Start with a simple title.

The User Story title is the core element of the user story. It tells the story of one portion of the experience that a hypothetical user would want in order to solve their problem.

There are many ways that this title can be formulated, but the most common, and my favorite, is:

As a <USER>
I want <SOMETHING>
So that <SOME REASON>

Here’s an example:

As a millennial
I want to take selfies of myself with dog ears
So that I can show my friends how quirky I am

The <USER> should reflect a real type of user that you believe this feature or product is going to be particularly applicable for. No good user story starts with “As a user”. Instead, talk about teachers, nurses, children, adults. However you’ve segmented your market, tell a story about how a particular segment of your market wants to experience this product.

A word of caution, the user story title is different from the title that a ticket might have in JIRA or whatever other utility you use to track stories. The full “As a… I want… So that…” title doesn’t translate well into JIRA ticket titles, so I’d advise that you use something succinct that is still experience focused — a brief title that serves to remind a team of conversations they’ve had on a particular user need, without prescribing what to build in order to meet that need.

Wireframes and pictures

When in doubt, draw a picture.

Researching and testing a product often involves drawing pictures and wireframes. Whenever possible, a user story should have any such relevant design and research materials attached to it. As the cliché goes, 1000 words are often easier to communicate through a wireframe than in a long rambling description of what needs to be built.

On a similar note, quotes from conversations with real users, summaries of relevant research, or recorded conversations with users are also great additions in this category.

Acceptance Criteria

Negotiate and test with simple and reasonably comprehensive.

A User Story is considered “done” when its acceptance criteria are met. As a result, user stories often work far better when those acceptance criteria are stated explicitly.

Acceptance criteria are often where we truly start to cross the line between the problem a user has and the implementation that will solve that problem. Since it is not a product manager’s job to dictate how engineers solve a given problem, acceptance criteria are often something that needs to be determined collaboratively with engineering.

Start with bullet points that describe the basic ideas of what this product needs to do.

This product needs to:
- Do this,
- and this,
- and this

bullets can be written quickly in a story-development workshop, and are easy to read. A user story has been completed when these bullet points are met.

Eventually though, we’re going to want to take these criteria a step further. Acceptance criteria are great for User Acceptance Testing (UAT), since they describe what it means for a product to successfully meet the needs users have. Bullet points, unfortunately, are often not descriptive enough to facilitate efficient testing though, and so we need another device.

Enter the Gherkin. The Gherkin is a great mechanism for writing easily understood and tested acceptance criteria. It’s form is fairly simple:

Given <SOME PRECONDITION>
When <SOME INPUT>
Then <SOME OUTPUT>

Here’s a more real example:

Given I've created login credentials
And I'm on the login screen
When I type in my correct username and password
Then I should be able to log in

If you’re getting really into the swing of things, your team might decide to start employing a tool like Cucumber, which has the power to turn plain english Gherkin-format acceptance criteria into automated User Acceptance Test, but I digress…

Iterating and Improving

No user story is going to be perfect when you first write it.

User Stories, like most other things that product mangers build, are meant to be iterative endeavors. Just as we strive to build minimally viable products, we also strive to start with minimally viable user stories.

The detail that a user story needs is determined by its place in your backlog. An ill-defined user story that is extremely high priority is unlikely to be completed well, and an overly-defined user story that is extremely low priority is likely a waste of you and your team’s time.

Start with bullet points, stubs, and placeholders, and work on adding detail as a user story rises to the top. I like adding “stage gates” to my user story writing process, wherein I have roughly defined points at which I need to make sure certain components are present.

By the time a user story is ready to be handed to an engineering team though, it had best be well written. There is no easier way to waste an engineer’s time than to hand them an ill-defined set of requirements.

Let’s not waste our engineers’ time.

Thanks for reading! I’m Jack Moore, and I love writing about product management.

If you liked this, you might also enjoy these:

Bored Product Managers Aren’t Doing These Things

This Is How Great Product Managers Interview Engineers