What Is a User Story?

Long story short, it’s a short and simple description of a software system feature and its value for a user. A user story depicts how an end-user sees this feature. It answers the questions: “Who is this user? What do they need? Why do they need this feature? How will they use it?”‍

This agile method helps development teams focus on discussing requirements. It’s a great way to shift the accent from the documentation about code to the entire functionality and how an end user sees it.

We’ll cover this topic in detail in a couple of subsections. 

User stories can be written digitally (in Word, Excel, Google Docs, and specialized software) or physically (on sticky notes or index cards).

‍

Why Teams Need User Stories

Every product owner, project manager, and developer knows that requirements are constantly changing. Projects progress, users learn more about them, their goals are changing as well. Delivering a project based on outdated requirements might mean a lack of demand and great losses on a competitive market.

Here come agile user stories! They reduce time on writing requirements and documentation and allow teams to be agile. Users get desired software more quickly, pay more for awaited features, which makes the project successful. 

‍

Who Writes User Stories

Anyone can tackle this. Product owners, project managers, business analysts, marketers, or other people involved in the software development project. In fact, no matter who writes a user story. The main thing is who discusses and enhances it.

‍

User Stories Basic Principles

The basic principle for successful user stories is proper storytelling. Every story should answer three fundamental questions about product requirements:

Who? What? Why?

Anyway, they should be brief, unlike ordinary stories. Each element usually consists of up to 15 words. From a bird’s-eye perspective, a user story should be like a concise “to-do” list clear for everyone. It helps teams make sure that the result will meet the requirements and customers’ expectations.

‍

6 Steps to Create a Great User Story

Before starting with your user story, check out the INVEST model used by professionals:

• Independent. Every user story should be a stand-alone story. It shouldn’t depend on new stories. If they do, merge them into a single one.
• Negotiable. User stories should be discussed, not just signed like a contract. It implies the participation of various team members, not only one who writes those stories.
• Valuable. The result of every user story should be a certain value for an end user.
• Estimable. Such stories should be estimated so that teams see whether they fit the current or future sprints.
• Small. If a user story takes you more than 4 days to complete it, this is a bad sign. Their implementation should take around 3-4 days.
• Testable. You should have acceptance criteria for further testing the results. They show you whether a story is confirmed or you’ve missed the goal.

‍

How to Write User Stories

Step 1

Think of the result. When will your story be done? At what point a user will complete the task in your story? You should be sure of the start and finish lines.

Step 2

Set tasks and subtasks. Define steps to complete. Split large tasks into smaller stories. Set responsible people for each of them.

Step 3

Set user personas. Create a single understanding of who is your perfect end user. Who will benefit from using your feature? Describe several personas with different stories.

Step 4

Divide a user story into steps. Describe which small steps are required to finish your story. Be attentive to the details and briefly describe every step in the clearest way.

Step 5

Collect feedback. When testing your story, ask for feedback from end users. Replace guesswork with real cases if you want your feature to succeed.

Step 6

Set deadlines. Estimating your work can be challenging, still, you need to see whether a story fits the sprint. What’s more, if it doesn’t, check if it can fit the next sprint or should be done later, probably, in the timeframes of an epic or several epics. 

Except for this guide, consider additional best practices, for example, 3C’s method.

‍

Writing User Stories With 3C’s

A user story has a general three-stage structure:

1. Card. Understanding the needs of customers. Write each requirement on a separate story card. This will help you focus on one thing at a time. Index cards are great for laying out the parts of the process on a table and moving them to see the entire picture. Shuffle priorities, move cards, optimize your workflow!
2. Conversation. Discussing the process of implementing plans into practice, the details of the project. This will help you identify and fill any gaps.
   — Introduce a user story to the team.
   — Seek clarification from team members with different roles. Get all the information you need.
   — Discuss further acceptance criteria.
   — Estimate deadlines together with the team.
   — Negotiate about the work done with stakeholders.
   This part is over only when an end user tests your user story. 
3. Confirmation. Testing that shows whether the story really works and its objective is met. Check whether a user is satisfied with the results.
   — Perform user acceptance tests.
   — Show your story results to the Product Owner and stakeholders.
   — Demonstrate the feature to real users and seek their feedback after deployment.

‍

User Story Template

Here we’ll talk about the formula mentioned at the beginning of this article. 

As a (user persona), I want to (perform an action), so that (I get some benefits).

Let’s break this formula down by parts:

• Persona. This should be a detailed image of a user, not just his job role or demographic characteristics. You should analyze your common type of users to see who they are, how they behave, how they think. A Persona is a more empathic image than just a set of technical patterns. You can even name your persona to make the image more congruent.
  Here are the examples of Personas done in the Flowmapp app:
  — Editor’s persona
  — UX designer’s persona
  — Software engineer’s persona

• Action. Describe a persona’s intent. Understand what they are going to achieve by using your feature. So, this point means even more than just the features they use. Long story short, add a goal to the process.
• Benefits. This is the most important part for users. If there’s no benefit, no one will pay for the feature. Your user has problems and they want to solve it. How does your feature help them?

‍

User Stories Examples

Let’s try using the formula from the above paragraph:

• As Alice (a project manager), I want to organize my files, so that I have more control over the project.
• As Tim (a copywriter), I want to use a tracking feature, so that I see who edits my texts and which changes they make.
• As Alex (a manager), I want to see the progress made by the team, so that I report our success to the CEO.

It’s simple! Describe your user, their desires and benefits from using your feature. Use our examples to make yours!

‍

Organizing User Stories With Story Map

When you have dozens of upcoming user stories, map them! This will give you a chance to prioritize features, organize tasks, plan sprints. Mapping user stories will show you a large part of the customer journey and let you notice gaps in it.

Here is an example of a helpful story map:

Actually, story mapping is not a short process. Still, it’s the backbone of your release. So, be ready to invest more time and effort than in planning sprints. Perceive creating a story map as a general planning session with a detailed overview of projects, iterations, or pivot points. 

‍

The main steps for creating a user story map:

1. Frame the whole process. Answer three major questions: “Who? What? Why?” Define what your product or its features will do.
2. Set the backbone for your story. These are all high-level tasks from A to Z. This will be your product backlog.
3. Group user activities. Group activities to take them to a more high-level perspective. For example, ‘signing up’ can require entering first and last name, confirming email, filling out a short poll.
4. Break tasks into subtasks or small user stories. If your story needs to be fulfilled step-by-step and in more than one sprint, break it into parts.
5. Prioritize subtasks and tasks. Start with the most crucial ones, and enhance your feature in the following sprints.
6. Fill in gaps. Seeing the entire map will make gaps visible. Don’t hesitate to ask for recommendations from colleagues who have a fresh look.

‍

User Story VS Use Case

These two concepts are very similar. Still, here are the major differences between them:

1. Use cases are about customers’ behavior while user stories are about needs. A story tells about a ‘raw’ need of a customer, next, a use case describes what a person does to fulfill that need.
2. User stories are often simple and easy to read. Use cases include technical details about interactions between the software and end users. The difference is in the number of details on functionality and the level of complexity.

‍

Software to Create User Stories

• Whiteboard. A classic method when you use cards or sticky notes to lay out a story.
• MS Office: Word, Excel, PowerPoint. Create user stories like any other flowchart. Use shapes to represent cards and write descriptions on them. Find the detailed instruction in our article about flowcharts.
• Google Docs. This tool is very similar to MS Word. If you are used to working with it, try making your user story in Docs. Here you can find a short manual.
• FlowMapp Personas. A professional tool for creating personas that can be included in user stories, customer journey maps, or flowcharts. All the design work is already done! You need only to:
  — Create personas for your major target audience segments. Use preset blocks to make your design perfect.
  — Customize elements of personas to make them original and good-looking.
  — Build professional user flows based on your research.
  — Collaborate online with your team to discuss personas and user flows. Achieve maximum efficiency!

‍

Bonus Tips: 5 Best Practices for Creating User Stories

Grab these bonus tips on how to create user stories!

1. Use Paper Notes or Cards

Before getting your user story to the digital dimension, try using paper cards. Group them on the table or move and replace with other cards.
Once you are satisfied with the pattern, document everything digitally, and share it with colleagues.

2. Focus on Users First

User stories are about...users! All in all, you will offer the feature based on this story to the audience, so you should clearly understand what customers need. Gather as much data about them as possible.

3. Keep It Simple

Use a simple yet concise approach. Stories should be easily perceivable. Don’t use ambiguous terms and complex phrases. 

4. Keep Stories Visible

Communicate data with both words and visual tools. Visualize processes and results to make one say: “I understand what’s going on here from the first sight!”

5. Don’t Rely Only on User Stories

Except for stories, use various tools to dive deeper into the behavior of your target audience. Customer journey maps, user flows, personas - all this comes in handy when improving your product or project. 

‍

Key Takeaways

You now have a bigger picture of creating user stories. It’s time to act!

1. Start with our step-by-step guide. For example, create your first persona in FlowMapp.
2. Continue improving your user story 3C’s or INVEST success formulas.
3. Finish with implementing best practices. 

And keep in mind three major questions: “WHO? WHAT? WHY?”