Product managers and PMPs use the term “user story” in agile. The word “story” is so overused, that it’s similar to the word “love” – both have many different meanings. Stories could be Snapchat posts, great books, documentary films, or (in the case of a user story) a communication tool. But what is a user story? And why do we call them stories?
If you’re looking to develop software, or to hire a software developer for your business, you’ll definitely want to write user stories.
An effective user story has three characteristics – who, what, and why. A user story typically follows the “As a (who), I want (what) so that I can (why)” format. An effective user story is estimable and usually achievable within a single sprint. User stories should be clear, concise, and provide a common language between technical and non-technical people.
The clearer your user stories are, the better each department can clearly understand the requirements and estimate the time needed to complete the work.
In scrum, user story mapping should be collaborative. User stories don’t necessarily need to have everything written out perfectly in advance.
Now, I’m far from perfect when it comes to writing user stories. I’ve found that the best user stories are written in collaboration with the team, rather than in isolation. A truly useful user story should provide a common language for team members with different skills. For example, marketing professionals and software engineers often seem to view the world in totally different ways — and that’s what is so great about user stories. User stories can unite teams with differing perspectives.
Stories are a universal way of communicating ideas. A user story is just a project management-specific method of writing stories with a purpose. One advantage of using the typical “As a (who), I want (what) so that I can (why)” is that it’s so standardized that any team member could familiarize themselves with the concepts quite quickly with just a few Google searches or a book or two.
Characteristic #1 – It tells you who needs the feature
Every user story should serve a hero. In most cases, this is one of your customers.
Your job as a team is to be the mentor to the hero. You’ve done the research to figure out your user demographics. You’ve joined every Facebook Group where your target audience hangs out. You now know what your ‘ideal customer’ looks like, and you have a clear picture of their problems.
Now comes the hard part – as a mentor, you get to invent potential solutions to their problems. I say potential because you don’t know if your solution will be helpful to the hero yet!
Some marketers and project teams like to assign names to their ‘ideal customer avatars’. But remember that a key characteristic of a user story is that it is clear. To keep things simple and avoid potential confusion, it might be safer to use customer roles like, “as a guest” or “as a paid subscriber”.
Examples of Roles:
Here are a few examples of potential “who” roles in a typical user story:
- First-time visitor
- Paid user
- Former subscriber
- Team member
Characteristic #2 – It describes an action a persona can take
This is the heart of the story for your hero!
In the case of TurboTax, the Intuit team simplified the personal tax return down to a much more human, easy-to-understand series of questions that allowed anyone to file their taxes quickly and painlessly. Intuit made the previous solution (filling out and filing taxes manually on paper) feel much more painful than their newer, better solution.
It doesn’t matter if you’re working with a freelancer, a contractor, or an in-house team — well-researched user stories are a powerful tool to unite people around a common goal.
Characteristic #3 – It explains the benefit of taking that action
This is where people believe in the idea, or they get hung up on it and debate it. If they do debate the feature, then that’s a good thing! It’s an opportunity to improve this user story, or scrap it in favour of fewer user stories or a better user story instead.
Remember, we want effective user stories, not shoddy ones. If a software development team is going to spend a week or more building this feature, the responsible thing to do is to ensure that the user story has been well-researched and explored.
Often, the team who’s closest to the customer will have the clearest idea of why a certain feature is valuable to a customer. If you have an customer service or client success team, it can be incredibly valuable to teach them how to write user stories!
Characteristic #4 – It can be completed within a sprint
“As a user, I want to add friends, upload pictures, and post status updates to my friends’ social feed so that I can connect with my entire list of acquaintances and colleagues.”-Tom from MySpace
At first glance, this example user story may seem achievable. However, it’s probably not likely that this could all get done in a sprint. As a general rule of thumb, user stories should be boiled down to simple little work items that can be completed within a single sprint.
A typical sprint could be as short as 1 week or as long as a month. But make sure your stories aren’t too small, either. If it’s just a simple task for a single person to get done in a couple of hours, it likely doesn’t justify the extra time and overhead required to write out a full user story.
Think of user stories at an ‘atomic’ level.
Instead, it would be better to break it down into a few smaller stories, like:
“As a small business owner, I want my payroll automatically calculated for me, because it is time-consuming and prone to errors when I do it manually.”-Generic Person
Characteristic #5 – It’s clear enough that team members can estimate the scope
In User Stories Applied, author and project manager Mike Cohn says:
“User stories provide us with a way of having just enough written down that we don’t forget and that we can estimate and plan while also encouraging this time of communication.”
The purpose of user stories is to make planned features clearer, so each department can estimate how long it will take to achieve the desired result.
One of the major benefits of user stories is that they help a team to put themselves in a customer’s shoes rather than their own. A user story
Characteristic #6 – The story is supported by ‘Acceptance Criteria’
How do you know when a story is finished? What is the definition of ‘done’? To a product owner, acceptance criteria is the difference between a truly completed story and an incomplete one.
Simply, acceptance criteria is a list of what must be done before a story can be considered ‘done’.
Let’s think back to the Hero’s Journey for this. How do you know that the hero has been successful in their mission? When the hero takes the action described in the user story, do they have that internal sense of satisfaction? Did the user story provide the hero with the benefit it promised?
Characteristic #7 – It doesn’t discuss specific technologies
Your user story should never include specific technologies. If your story includes words like React, Vue, Vulcan, Elixir, Redis… you’re doing it wrong.
Jargon is a surefire way to exclude stakeholders, other members of the team, and customers. Remember that a user story is intended to help you create clarity.
I look at it like this – a user story is something shared across multiple teams. You don’t need user stories you’ve written in Jira to be a duplicate of the conversations in Bitbucket or Github.
Tip: Use acronyms to help you remember
Bill Wake created this mnemonic for agile software development. This is my favourite acronym for user stories. It’s a bit longer, so it can be more difficult to remember each of the 6 words.
- Independent of other user stories
- Valuable to the customer
SMART is the easiest mnemonic to remember. I’m not a huge fan of this one, personally, but it may work for you.
SMART stands for:
I prefer the way the guys at Manager Tools look at SMART goals. They just focus on the two most important letters of the mnemonic: Measureable and Time-Based.
If your user stories or goals are Measurable and Time-Based, then they’ll automatically be Specific and Actionable. Why would you set unrealistic expectations, anyway? Setting unrealistic expectations is a recipe for team frustration.
The Three C’s
This one doesn’t necessarily ‘spark joy’ in my mental attic, either. But rather than Marie Kondo-ing the Three C’s out of this post, I’m sharing them in case you find them helpful:
- Card – the written card or sticky note, typically using the “As a (who), I want to (take action) so that I can (get benefit)” format
- Conversation – discussion about the story, usually facilitated by the Product Owner
- Confirmation – typically the product owner should confirm that the story is complete before it is considered ‘done’.
User Stories vs. Tasks
|Written from the user’s perspective. It’s not about you, but them.||What do we need to do to complete the user story?|
e.g. Rebuild the Elastic server cluster to make it more performant.
User Story Examples: Login
As a registered user, I want to login so I can access subscriber content.
Don’t worry too much about writing perfect user stories. What’s most important is that your team is working together towards a common goal with a common understanding of the time required to complete the work. User stories provide a common language for teams to work together across various boundaries. When in doubt, talk. Get in front of a whiteboard and practice writing out user stories together. You’ll be much further ahead if you’re aligned.
If you want to get really fancy, you could create a template in Excel or Airtable using the “As a _____, I want ________ so that I can ______.” format.
Either way, unless you want a task list full of vague tasks like “Redis cluster on dc4” or “Implement a request button”, it’s wise to leverage user stories to define your work. If you can make this shift, it can help align your team and make them even more goal-driven and customer-focused.