How To Create User Stories

What is a user story?

A user story is a short, written explanation of a particular user’s need and how it can be fulfilled within the Agile development lifecycle. These stories are designed to focus on the end user and are generally written in layperson’s terms for easy accessibility.

Every user story involves a short-form request that is completed in one Agile iteration or sprint, which normally lasts about one or two weeks. Teams measure the complexity of their user stories with story points, helping them to accurately estimate how long a particular request will take.

A collection of user stories in Agile is referred to as an epic. A product owner will be responsible for managing the epic, but they can be written by any Agile development team member.

A user story is similar to a use case but is not as detailed. The former is a very brief description of a planned action item, while the latter will likely contain extra sections such as conditions of satisfaction, various paths a user might take in using a product, and workflow diagrams.

Extreme programming (XP)

XP also dates back to the 1990s, when it was founded by Kent Beck and later developed by Ward Cunningham and Ron Jeffries.

According to the Agile Alliance, user stories actually originated within the XP framework, where they were described as “game pieces” in project planning. With an emphasis on short work sprints, constant iteration planning, and thorough collaboration with stakeholders, XP is perfect when encountering customers who are unsure of what they want.

User story examples

It’s time to discuss what a user story entails. Within the Agile approach, the user story format is quite simple, outlining the “who,” “what,” and “why” of a particular requirement.

• Who wants something?
• What do they want?
• Why do they want it?

Take a look at this user story template, which depicts the three elements above in one succinct sentence:

“As [persona], I want to [action], so that I can [benefit].”

For each story, the writer will include a user persona, the action they wish to take or the ability they wish to have, and the benefit they hope to achieve as a result. Here are some examples of user stories applied to three diverse personas:

Example 1: An online gamer

“As an online gamer, I want to have a multiplayer option so that I can play online with friends.”

Example 2: A design team lead

“As a design team lead, I want to organize assets, so I can keep track of multiple creative projects.”

Example 3: An e-commerce shopper

“As an e-commerce shopper, I want to filter my searches so I can find better products quickly.”

Now that you know what a user story example looks like, you can get to work creating one.

5 steps for writing user stories

Want some practical advice on user story writing? Use these five steps as a guide:

Step 1: Outline acceptance criteria

The definition of done is the set of criteria that needs to be fulfilled for your user story to be considered complete. Define the specific acceptance criteria and use it as a checklist.

Step 2: Decide on user personas

Conduct extensive user research by creating surveys, hosting focus groups, and reading user forums. Analyze your data and search for patterns to identify your key personas.

Step 3: Create tasks

Break your story down into numerous tasks to make it more manageable. If it is a complex requirement, you can also add subtasks. Include detailed descriptions, so your team is aligned on what each task requires.

Step 4: Map stories 

Use user story mapping to structure work in a large process. In this case, your stories will take the form of ordered steps.

You can craft your story maps using handwritten notes, index cards, or project management software.

Step 5: Request feedback

Speak to users and potential customers to find out what they want. Ask them for their opinions on existing products or if they have suggestions for new features. Incorporate this feedback into your user story.

Remember that noting the user perspective is of paramount importance, as you can incorporate this feedback into your user story.

What makes a good user story?

So, your Agile user story is complete and ready for review. Time to gather your Agile teams to assess your story quality via the INVEST acronym. This stands for:

• Independent: The user story should be independent of all others. Because they are not connected, they can be worked on in any order.
• Negotiable: A user story should be flexible enough to encourage and allow for negotiation between the customer and product owner.
• Valuable: What value does the user story bring? If you cannot find any value or desired functionality, the story should not be completed.
• Estimable: You should be able to make an estimation of how long a user story will take so that you can effectively manage your time.
• Small: The story must be small enough to be completed within a single sprint.
• Testable: You must be able to test your user story in line with quality assurance standards and obtain confirmation through acceptance testing (e.g., beta testing).

If a user story does not satisfy the INVEST checklist, it should be rewritten or removed from the epic. However, if it does, your team members can get to work. Schedule daily Agile meetings to check on their progress and evaluate if they are on track to complete the user story within the sprint time frame.

Bigger vs. smaller stories

Unsure of whether your team should gravitate toward bigger or smaller user stories? While bigger stories may offer more information, smaller stories offer several key advantages:

• Focus: Since small stories have a narrow focus, they won’t overload you with too many details like a larger story would. A smaller story helps to avoid confusion, so that your team can better collaborate and get things done quicker. Keep it short and sweet!
• Reduced risk: The bigger the story, the higher the risk that your team will not have a deliverable ready by the end of the Agile sprint, since your resources will be spread. For instance, a developer with a specific skill set may be the only one who can complete your team’s stories. However, breaking them down into smaller ones will prevent your team member from burning out.
• Transparency: Smaller user stories allow your team to better view and track progress. Bigger stories have various moving parts, and it will be more challenging to convey how your project is coming along when it’s time to participate in daily standups and meetings with relevant stakeholders.

Benefits of user stories

Why write user stories in the first place? Because they offer numerous benefits for an Agile project. Here are a few examples:

• Simplified format: User stories are written in tangible, easy-to-understand language. This eliminates confusion and makes it easier to grasp what the customer is looking for.
• Increased flexibility and creativity: Because user stories don’t go into technical detail, they can be molded to fit changing situations.
• Improved collaboration: When team members are aligned on one goal, they can work better together and collaborate easily with other project stakeholders.

Though the benefits of writing user stories are significant, a product manager must also consider the potential disadvantages.

Disadvantages of user stories

Here are a few user story pitfalls to watch out for:

• Incomplete stories: Though the language is intended to be informal, sometimes user stories are far too vague and exclude necessary details.
• Insufficient time: Writing a good Agile story takes time, as it requires extensive research. Regular communication and a shared understanding with stakeholders are also needed and sometimes overlooked.
• Narrow vision: Because user stories focus on one single requirement, they can be hard to scale, and teams can sometimes lose sight of the bigger picture (in this case, an epic).

Before you start your story, take some time to identify potential risks or disadvantages. Be sure to hold a discussion with your team to outline how you aim to counteract them.

Take your user stories to the next level with Wrike

Now that you know how to create a user story, it’s time to work on the breakdown of your project. Wrike has the perfect solution for that.

With Wrike’s software, teams can easily implement Agile methodologies using custom workflows, Kanban boards, and prebuilt templates. These features enable teams to kick-start projects quickly, visualize and progress, track time, manage tasks, and collaborate effectively. Agile software development teams can also use Wrike to prioritize product backlogs, manage sprints, and run retrospectives.

Want to ensure good project outcomes on the horizon? Unlock the full potential of Agile methodology with Wrike’s customizable template.