User stories are a bit like a double-edged sword.
When written properly, user stories can give your team a different perspective and help them understand the intricacies of what’s needed to ship quality features.
But on the other hand, poorly defined and unclear user stories can turn on you and cause misunderstanding within the team.
Not to forget, there’s also this other problem of having to write a “story”, and not functional requirements.
No, really! Every time you give requirements to your team, they have a hard time understanding what the feature should do. They’ll come to you with more functionality they think should be added, only for you to repeat the phrase “But that’s not what the user wants!”
When done properly, user stories let your team stay focused on satisfying the user’s needs. And stop you from building a clunky, cluttered software.
TOPICS COVERED IN THIS GUIDE:
- How to write a good user story?
- Templates to write the perfect user story
- 5 best practices to keep in mind while writing user stories
- Benefits of writing user stories
How to write a good user story?
User stories are short, simple descriptions of how a feature will be used. They are written in an informal, natural language, from a user’s perspective. It reflects their need and the goal they intend to achieve by using your feature.
That means, user stories do not contain technical details of how the feature will be built nor contain feature specs. As the name suggests, they will have only a story of why your user will use a feature and for what benefit.
If you think about it, every feature you build has little to do with advanced functionalities and everything to do with satisfying the user’s needs.
Writing a user story might seem like an easy thing, once you’ve collected enough information about your users, their needs, and what their goals are.
But when the feature’s quality is on the line and depends on how well you define the user story, you simply can’t sit back and hope for the best, can you?
Templates to write the perfect user story
Writing a user story that everyone in your team understands, simple, and is to the point without technical details can be hard. The further you drift away from talking from a user’s perspective, the more details you’ll add and lesser useful it’ll be for you and your team.
Luckily you can take the below templates to write user stories and unite your team to focus on one true cause - solving your user’s problems.
- Role - Feature - Reason format:
Also known as the Connextra format in recognition of its origin when it was created at Connextra in the UK.
As a [role] I can [capability], so that [receive benefit]
- Another version of writing a user story:
As a [particular user], I want to [be able to perform/do something] so that [I get some form of value or benefit]. There are several templates floating on the internet to help you write a user story. But at its core, if you want to write good user stories, you need to define 3 things:
User Persona: The person who is going to use the feature. Personas are often a fictional character developed based on real data.
The persona’s need: What the user persona wants to do, or what functionality/feature they want.
The persona’s goal: Why they need the particular functionality/feature and what benefit they want to achieve from it.
The hard part is getting these 3 data points accurate. You need to do your research, talk to your users, and understand their needs. And only then, with enough information collected, you’ll be able to write good user stories using this simple template:
As a [persona], I want [need] so that [goal].
5 best practices to keep in mind while writing user stories
- User stories are independent of each other:
Every user story you write should be independent of each other. If you think one user story is dependent on the other, you’ve broken down the story too fine. Similarly, if your user story is too broad, it’s most likely an epic.
Keeping user stories independent of each other helps you while prioritizing your backlog. When dependencies come into play, it may not be possible to implement a valuable story without implementing other much less valuable stories.
Simply put, a user story by itself should be a working, usable feature your users can use and gain value from.
- Don’t confuse user stories with tasks:
A user story may contain several tasks and subtasks. But a user story itself isn’t a task.
Tasks and subtasks are about the finer details. They are about the implementation. The “how to execute it” of your feature. User stories, on the other hand, are kept at a meta-level; it talks about the why and the what of your feature.
- Provide value to users:
The gaps between your user’s pains and the solutions they have today are your feature’s real playground. And if your user stories aren’t going to fill in those gaps, you are better off not working on them.
Besides, would you rather work on a feature that moves the needle for your business? Or work on something users barely find value in?
Every user story you prioritize and work on should provide your customers with value and solve their problem.
“But what about tech debts, bugs, and improvements”, I hear you ask.
Tech debts and improvements have their place in your product backlog and must be prioritized as well. Otherwise, you’d end up building a legacy software that is slow and buggy. But they aren’t a user story unless they provide your users with actual value.
If you’re using Zepel, you can add your tech debts and improvements as an Enhancement. And of course, User Stories, Bugs, and Tasks (and subtasks) too.
- They are negotiable:
Since a user story doesn’t talk about the implementation, it should allow room for discussion, so when you collaborate with the team everyone can discuss and agree on the specifics of how to implement of the feature.
This lets your team understand the complexity involved and come up with creative ways to implement without being confined to a specific method.
- Big enough to be broken down to tasks and estimable:
You probably have plenty of user stories on your backlog by now and wondering how to prioritize one over the other and which ones to filter out.
The first instinct would be to start by discarding items from your backlog, I get it. But you’re better off by starting with breaking down your user stories into actionable chunks of tasks and estimating your user stories first before you can discard them.
With an estimate of how long your user story is likely to take, you can work with your team to find what minimum set of functionality is needed to help your users solve their problem and achieve their goal.
Benefits of writing user stories
A solid user story lets you anchor your communication to what matters most to your users while collaborating with the team. You get to pass every feature, functionality, and activity you do through a simple filter of “how does this matter to my user?”.
But at its core, the benefits of user stories can be summed up with these four key points:
- They keep the focus on the user
A list of tasks and subtasks are great if you want to get repetitive work done and keep your team focused. But when you are out to build a product that solves your user’s problem and satisfies their burning need, you need to keep your team focused on your users. Not checklists.
With every story focussed on your customers, your team will have an easier time focussing on the things that matter - your user’s needs!
“In a sense, there’s just one mistake that kills startups: not making something users want.” ~ Paul Graham
- Help prioritize key functionalities
Remember that time when your QA team came to you in the eleventh hour with a bug that popped up out of nowhere?
Everyone in your team was pumped and eagerly waiting to see the new feature hit production. Your developers were preparing to deploy. And you were left to decide if you should fix the issue and then deploy. Or if you should deploy with the bug.
Sure, if the bug is a showstopper, you have no choice but to fix it before you deploy. But what about bugs that aren’t a big enough to stop the entire deployment?
It’s hard, isn’t it?
Simply asking yourself “will this bug stop my users from achieving their goal” can help you prioritize better.
This same principle can be applied to an enhancement when it knocks on your door asking to be added to your existing feature.
- Enable non-technical members to contribute and collaborate
Building modern software is complex. It involves a wide range of technologies and implementation processes that can confuse other members of the team.
Since user stories are written in simple, non-technical language, it helps members from other functions of your organization like designers to chip in with ideas and help in deciding how to best serve the user.
- Focuses on the problem
It’s easy to jump straight in and drown yourself in a pool full of viable ideas, rather than taking a step back and focussing on the problem itself.
Starting with “What” - the solution - creates defensive teams. But when you start with “Why” - the problem - you get to rally your team around a problem and promote creative ways to solve the problem at hand.
The digitization of the project management industry has standardized the use of tasks and issues. They work just fine as long as you want to complete a few chores and fix some issues.
But if you’re trying to build a product that doesn’t just satisfy your users but also solve their problem, you need to get your team to focus on your user’s pain points and their goals.
By using user stories, you describe the why (and the what) behind your development team’s day-to-day work and ensure they aren’t checking off just a bunch of work items from your project management tool. But working towards building features your users need and move the needle for your business.
So, the next time you build a new feature, fire up your Zepel account and create user stories before you start adding tasks.