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.
So, how do you 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 that reflects their need and what 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?
Here are five things you need to keep in mind to take your user story from good to great:
1. 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.
2. 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.
3. 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.
A list of user stories, enhancements, bugs, and tasks in Zepel
4. 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.
5. 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.
Templates for writing 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.
1. 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]
2. 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, to write not just good but great user story, you need to define 3 things:
1. User Persona: The person who is going to use the feature. Personas are often a fictional character developed based on real data.
2. The persona’s need: What the user persona wants to do, or what functionality/feature they want.
3. 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 research, talk to your users, and understand their needs. Once you’ve collected enough information, you should be able to write a user story by filling up this template:
As a [persona], I want [need] so that [goal].
But what are the 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:
1. 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
2. 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 is pumped and eagerly waiting to see the new feature hit production. Your developers are preparing to deploy. And you are left to decide if you should fix the issue and then deploy. Or if you should deploy with the bug. What do you do?
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 ask yourself if the bug will stop the user 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.
Related read: How to prioritize the right features
3. 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.
4. 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.
Define when user stories are complete with Acceptance Criteria
Acceptance criteria let you define when your user story is complete and has all the functionality needed to meet your user’s needs.
They are a set of conditions a user story should satisfy to be considered as done. It provides a detailed scope of the user story and what is needed so your team can understand what they’re up against. That way, every time you ship a new feature, you can be sure the feature meets the standard your users deserve.
But before you enthusiastically declare a set of functional criteria that should be met for your user story, consider how other variables can impact the quality of your feature as well and include them into your acceptance criteria.
Acceptance criteria can include:
User experience
The current user story’s effect on existing feature
A key performance like speed
What the feature was intended to do
Note: Like user stories, acceptance criteria is not a task. They are a technique for adding functional details to user stories.
So, based on the feature you are building and its complexity, figure out what minimum subset of functionality it should perform and how it should behave. If it’s complex or a core feature of your product, you should consider writing as many and detailed acceptance criteria to help your team avoid any confusion.
Template to write acceptance criteria
To make life easier, here’s a simple template you can use for writing acceptance criteria:
Given [context] when [a specific action is performed] then [a set of consequences should occur]
Example of acceptance criteria: Given I am on the sign-in page when I enter my username and password to login then I should be taken to My Dashboard page.
In Zepel, we recommend users to add all acceptance criteria as a description to the user story, so when your team members pick it up, they have the full picture of what’s required to complete the user story and its related discussions all in one place.
A user story in Zepel with Acceptance Criteria
Conclusion
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.
Top comments (0)