IT software projects face dozens of issues and challenges. And they fail pretty often. From inefficient project management to lack of demand for the planned product, there are so many potential risks that it’s barely possible to protect from all of them. However, we still can mitigate a huge pack of these risks just by understanding customers a bit better.
As you can see, IT projects fail to meet requirements, exceed initial budgets and schedules. Talking about the exact reasons for these problems, TechRepublic reports that the most widespread project failures include user discontent and poor user experience.
For sure, all companies would like to get a magic potion to learn everything about clients and, what’s equally important, share this knowledge with employees. Well, there’s no such potion. But there’s a tool with a similar effect. It’s called user stories.
In this guide, we want to show you how the concept works, how to use it with the best results, and why you should start writing user stories right now. Let’s go!
What Are User Stories And Epics
The idea of user stories is a cornerstone of the Agile methodology. It provides for making short and precise texts on behalf of the user. The final goal is to switch from writing requirements to discussing them, understanding customers. It’s simpler to get the idea by looking at the template. This one is often used in many cases:
You can check the detailed breakdown of this template in the section with examples.
It’s essential to understand that user stories don’t equal requirements, tasks, or features. It’s a separate unique piece of content for the development team. Writing user stories, you combine customer data and requirements, translate them into a simple, clear, non-technical language. After reading a user story, devs should understand why are they building the product and how this product will help end-users.
In Agile, stories represent the smallest scope. They form a bigger level called epics. One epic is a topic or cluster that includes interrelated user stories with the added requirements. Often, epics are just huge user stories that can’t be processed at once. Hence, teams divide them into smaller pieces to analyze customer needs one-by-one, fulfill them efficiently.
In the next two sections, you can find five reasons to start writing user stories and one case when it’s better to avoid them.
Top Reasons To Create User Stories
Compared to other methods of gathering customer data and documenting requirements, user stories have a few benefits. Undoubtedly, you can get them only if you know how to create solid stories. Later, we will show how to do this. But now, check these essential advantages:
- Active collaboration thanks to which the team unites and works together effectively.
- Focus on the customer, core pains, and wishes of the potential audience.
- Full clarity that shows responsibilities inside the team and between teams.
- Progress and achievements that stimulate the team to work further.
- Tolerance to creativity that enables various solutions to current challenges.
One Case When Personas and Stories Don’t Work
Remember the user story template? You may notice the word “persona” in it. The thing is that user stories rely on the concept of buyer’s personas heavily. They require segmenting your clients to identify common features, needs, pains. But this approach fails when it comes to products/projects for which customer segments can’t be set.
In this case, it’s better not to start writing user stories. Instead, you may be interested in the alternative job-to-be-done format. So-called job stories focus on situations and tasks instead of personas. For them, the basic template looks like this:
“When I’m in <situation>, I want to
See this difference? We’ve changed the first part only, putting the situation instead of the user. But this approach works in cases when user stories are obsolete.
On top of that, we should mention that writing user stories isn’t a cakewalk. If you can’t create an insightful and professional story, it’s better not to create it at all. Poor descriptions are vague ambiguous texts full of assumptions. Instead of guiding the team, they lure it away from the real wishes and pains of customers.
Anyways, our topic focuses on user stories. So, let’s learn the mastery of writing user stories that bring value.
How To Write User Stories: Examples And Acceptance Criteria
To write the best story, any team or person should start with research. It’s a good idea to start by studying your audience and defining its needs. Then, design the major epic – the next (or first) big topic that you can divide into smaller user stories. For each story, identify its core elements: a person, a desire, and a consequence. Finally, be sure to discuss stories with colleagues to exchange ideas.
Overall, the flow of writing user stories looks as follows:
- Gather info about your customers.
- Describe your users, their intents, and the desired benefits.
- Add details, for instance by setting subtasks.
- Define the acceptance criteria to know when the story is done.
- Iterate and prioritize but don’t discard stories.
- Repeat for the next epics.
Further, let’s answer a few frequent questions about user stories. Apart from the main flow, there are critical aspects such as authors, the best moments, and examples.
Who Writes User Stories?
Honestly, anyone can do it. Traditionally, user stories are the responsibility of product owners and project managers. But other team members can design them, too. It’s a good exercise that helps your colleagues to understand customers and the product you’re developing for them.
Copywriters, UX designers, social media specialists, software engineers, QA experts – all of them should participate in writing and discussion.
When to Write User Stories?
While the team can generate stories during the entire sprint or project, it’s a good idea to start with them. One or a few workshops can help you to understand customers and get the basics of writing user stories. The main goal of such seminars is to describe the product’s functionality in full, see it through the eyes of users.
Some of the initial stories will become epics, others will be abandoned, and it’s normal. Don’t forget that new ones can be added at any moment.
Well, What’s About the Examples?
As we’ve mentioned above, a typical user story has a pretty simple layout. Let’s remind it:
“As a <user or persona>, I want to <do something> to <get some result>”
Usually, the template is one sentence with three core elements:
- A person. It’s your average customer. Each project may have several personas depending on the features and values. For example, both solo travelers and agencies can use ticket booking apps. Thus, you want to define two personas.
- A desire. Here’s the major intent but not the feature itself, mind the difference. Through desires, your clients tell what do they want, actually, not how you implement anything. This part should be UI-free as it focuses on the wishes of real people.
- A consequence. It’s the outcome a person wants to achieve through the aforementioned intent. In the consequences, you can add the main user pains or general benefits they’re looking for.
Now, as you know the basics, check the examples of stories. Feel free to practice by writing user stories related to your product, user personas, and features. Note that it’s better to use actual human names to make your personas more living. Here, we use positions and titles instead but it’s to clarify the structure only:
- As a busy manager, I want to prioritize tasks to improve my efficiency.
- As a CEO, I want to see all the reports to define further strategies.
- As a movie fan, I want to compare ticket prices to get the best offer.
- As a parent, I want to check my kids’ locations to be sure that they’re safe.
- As a system admin, I want to filter files to see fresh updates.
5 Crucial Tips For Writing Great User Stories
Apart from the structure and general workflows related to stories, there are a few master hints we want to share with you. They’re platform-independent. In other words, you can use these tips for any process, whether you’re writing user stories in Jira or handling them via sticky notes.
Here are five core suggestions that can help a lot:
- Don’t try to do everything at once. Agile methodologies are great because they allow you to set different scope levels. If you can’t complete a user story within one sprint, divide it or turn it into a separate epic.
- Group and prioritize. As long as the described approach relies on creativity, you may found yourself surrounded by various user story drafts. Don’t delete them. Learn to set labels, categorize stories, and prioritize them to keep things clear.
- Think like a user. We can repeat it several times. To make a successful story, you should understand customers perfectly, rely on user data, and actually be users, look through their eyes.
- Use tech specifications. User stories can’t replace tech documents because they have a different purpose. Ideally, the team should combine user stories and specifications, switch between two types to know all the details.
- Visualize. Remember this categorization hint? Don’t stick to texts only. Use story maps, tags, and buckets to visualize the project’s flow. It’s especially useful for cross-team collaboration as your colleagues can get the idea quicker.
Undoubtedly, don’t stick to these hints only. Do your research and gather the team’s experience to design the best user stories.
Secrets Of Writing User Stories In Jira
Being one of the most powerful Agile management tools, Jira has functions for writing user stories, surely. It’s pretty simple to start. You should navigate to your project screen or backlog, tap to create a new issue, and choose its type – Story. For Agile teams, it’s better to fill their backlogs with user stories at the beginning of the project. Further, based on these issues, you can plan the entire lifecycle.
Each Story-type issue has typical fields such as its summary, priority, due date, assignee and reporter, description, etc. Stories can be assigned to epics and sprints, as well as divided into tasks and subtasks. Finally, there are convenient estimation tools in Jira. For instance, you can use the Fibonacci numbers to estimate your stories’ scopes, decide whether they fit into one sprint or should be decomposed.
Check out a few extra tips for writing user stories in Jira:
- Feel free to discuss, leave comments, and change stories.
- Focus on business and customer values, not tech specs.
- Make them independent so they make sense even when put apart from other issues.
- Remember about 3 C’s, including cards, conversations, and confirmations.
- Use tasks and subtasks to define features, requirements, and actual work.
Source: wibas blog
Understanding The User Story In Scrum
User stories in Scrum are similar to ones in Agile. The thing is that Scrum is an Agile framework. It relies on sprints that last from two weeks to one month, each with specific features and goals. Scrum teams use these sprints and smaller tasks to divide big projects into smaller portions. This approach helps to deliver the required features within fixed periods.
A backlog is one of the core elements here. Basically, it includes all the features for future releases. Some teams think that the entire Scrum backlog of any project should consist of user stories. Nevertheless, user stories represent only one Scrum artifact. You still can add other types to your backlog if it fits your team.
Check our tips to be able to write and discuss user stories efficiently, without overfocusing on them:
- Don’t be afraid to use other templates if they work better.
- For non-IT teams, it’s better to focus on outcomes, not full stories.
- Mind the purpose of user stories, use them only when they fit your backlog.
- Stick to bi-weekly or weekly sprints.
- Use other options to capture requirements.
User Stories for Testing Tasks
Summarizing this guide, we have only one thing to remind. While user stories are great tools, you shouldn’t forget that they rely on the statuses just like other Agile/Scrum features. In other words, each user story can be started, processed, and done. This last status is pretty critical. Any story can be completed when it meets the acceptance criteria – points that the team defines for each issue independently.
Ultimately, to ensure that your user story is done, you should test it. Let’s say, there’s a caring mother who wants to check GPS info to ensure that her kids are safe. In this case, acceptance tests should include various processes: can mother access the feature seamlessly through the chosen interface, how kids enable their trackers, is it convenient to use GPS, is the tracker working fine, how data moves from one device to another, and so on.
Testing is essential for teams that are writing user stories. Without tailored tests and positive results, you can’t consider any story done. Respectively, you can’t be sure that your users get their wishes fulfilled. Remember about tests and make great stories!