How to Write Epic User Stories
As a [button presser],
I want to [have a button]
so that [I can press it].
Technically speaking, that statement above is a user story written in the proper format. But as you probably noticed, it’s not a very effective one. It doesn’t tell you anything substantive about the user, what they want from the product, or why it matters to them — three things every good story needs.
The good news is that writing epic user stories isn’t some complex, mysterious formula that only experienced product professionals can do well. There are many more difficult areas of product management — making smart prioritization decisions, building roadmaps that don’t suck, etc. — that will take time for you to master. With the guidance we’re going to give you in this post, though, you’ll be writing excellent user stories in no time.
But that doesn’t mean the process is easy. Drafting a user story that’s clear and compelling takes a lot of hard work. It also requires avoiding the common pitfalls in user stories that can lead to confusion, wasted time and resources, and, in the worst cases, poorly made products.
So let’s get to work. First, we’ll explain what an epic user story is and where it lives in the larger context of your product strategy. Then we’ll show you how to write a great one.
And if you’re looking for an easy jumpstart to writing great user stories — including fill-in-the-blank templates for various story formats — you’ll find it all in the craft.io product management platform.
Try craft.io for free
What Is an Epic User Story?
We’re not high-school students here at craft.io, so when we say “epic user stories,” we don’t mean stories that are really cool. We’re talking about user stories grouped together under a related body of product development work called an epic. Here’s what that hierarchy looks like.
The agile development hierarchy: theme > epics > user stories.
If you’re creating a new product under the agile development framework, you’ll start with a theme — a high-level strategic idea or initiative. As you think through how to bring that big theme to life, your team will come up with several epics — large bodies of work that each support the theme in different ways.
And finally, you’ll break down each epic into smaller units of work, each representing a single goal or desired outcome from your product. These individual units of work are your user stories — epic user stories in this case, because they all roll up to a common epic.
(Oh, and in case you’re very new to the product profession, you should also know that user stories and use cases are very different things.)
The standard format for an epic user story.
There are several ways to write a user story. Some product teams use the problem-solution approach. Others prefer the a/b test format. But by far the most common — and the most effective, we believe — is the short statement format below.
As a [type of user],
I want to [goal]
so that [reason].
Looks simple, right? And it is. But don’t let the concise, plain-language sentence construction deceive you. You’ll need to think carefully about how to fill in the blanks here. Poorly written user stories can confuse and mislead more than they explain and guide.
How to Write a Great User Story (and Lots of Ways to Write a Bad One)
Imagine your SaaS team is coming up with ideas for a new product: an app that lets traveling professionals record and submit expenses while on the road. One piece of functionality you want to include is the ability to photograph a paper receipt (say, a restaurant bill) with the user’s phone and upload it to their expense report.
Even using the simple format above, there are several ways you could fail to capture that sentiment in your user story. Here are a few examples.
User story mistake 1: the poorly defined user.
As a [businessperson], I want to [connect this app to my phone’s camera] so that [I can scan photos of my receipts].
The user persona for this app is not just any businessperson but a professional who travels frequently for work. This is someone who generates a lot of business receipts on the road and needs to record and upload them frequently. The developers will need to build with this fact in mind.
Without that key detail, the developers and other stakeholders who read this story miss the defining value proposition that this functionality offers its intended user: the ability to record and submit company expense reports from the road.
User story mistake 2: the misunderstood goal.
As a [professional who travels frequently for work], I want to [connect this app to my phone’s camera] so that [I can scan photos of my receipts].
This time the writer did a good job of explaining the type of user but then described the desired outcome in a way that fails to identify the objective of that user.
Does the traveling professional want this new app because it will connect to their phone’s camera? No. That’s only a background detail supporting the user’s actual goal — the ability to easily photograph and submit their receipts to the company for reimbursement.
User story mistake 3: the unidentified value proposition.
As a [professional who travels frequently for work], I want to [be able to photograph paper receipts with my phone and pull them into the app] so that [I can scan photos of my receipts].
Now the writer has done a good job with the first two sections of the statement — identifying the important traits of the user and describing a solid goal that this user would want to achieve.
But in the final part of the story — the why — the writer is missing the opportunity to articulate the overall value proposition the functionality brings to the user. Is scanning photos of receipts the user’s end goal? No. A key component of the value is that this will save these users time and allow them to submit from their phones.
And leaving out that key detail can lead to development missteps. For example, if the developers don’t understand this part of the value proposition (that the user persona can easily capture and upload the many paper receipts they have to deal with during a typical workday on the road), they might design a workflow that allows scanning receipts with the mobile app but requires users to complete the final report submission from their desktop computers.
So let’s pull this all together…
The right way to write this user story.
As a [professional who travels frequently for work], I want to [be able to photograph paper receipts with my phone and pull them into the app] so that [I can easily complete and submit expenses from the road without wasting a lot of time].
Things to Remember When You’re Writing Epic User Stories
1. You’re not the developer.
Often a Product Manager or Product Owner writing a user story has the mistaken idea that the story will be clearer or easier to complete if they include a bit of technical advice.
The online community AgileConnection offers a great example of a user story whose writer snuck in some technical direction when it was neither necessary nor even the best suggestion:
As a Manny’s food service customer, I want to see different food item types displayed in different colors—RGB = #FF0000 for meats, #A52AFA for grains, and #808000 for vegetables and fruits—so that I can quickly identify my food items by food type.
Another example, in a software company, might be a writer stating the user wants to “choose from a drop-down menu,” when the software developers might have ideas for displaying the options more conveniently for the user.
Remember that your goal in writing epic user stories is to explain succinctly what your user wants to do and why it matters to them. Leave the how to your developers. They know that stuff better than you do.
2. You’re not a novelist.
The average fiction book for adults is 90,000 words. For books written for elementary-school children, the typical word count is in the 5,000-10,000 range. When you’re writing an epic user story for your development team, you’ll have about 50 words. And 25 would be better.
One of the ingenious things about the standard user story format — As a [type of user], I want to [goal] so that [reason] — is that it forces product teams to understand what they want and why for their user so clearly that they can explain it in just one plain-language sentence.
If you find yourself writing lengthy statements to describe your user or the problem they’d like to solve, that could be an indication that you need to give your proposed story more thought before you write it.
3. You’d better have your theme and epic written.
To be effective in your product planning, you need to take the top-down approach. First, you come up with a big-picture strategic theme. Then you translate that theme into epics. And finally, you break those epics down into the smallest self-contained units of work — the user stories.
Why is this so important? Because the theme and epic are where your team will draw your understanding of both the user persona you’re trying to serve and that person’s goals and the value they’re hoping to achieve.
In the example above, if the writer hadn’t been clear that the user would need to complete the entire expense submission process on a mobile device — because they’re always on the go — that could have led to misinformed development choices.
That’s why you’ll need to start with your theme (“Enable entire expense workflows on the road”), then the epic (“Make mobile submissions easy”), and finally your user story (“Scan and upload receipts from your phone”).
We hope this guidance helps you make your epic user stories… epic.
— Team craft.io
Try craft.io for free
