How To Write A Good User Stories

Your users are your best customers. They should be happy, satisfied and engaged with your product or service. The key to writing good user stories is to understand your user’s needs and wants. What problems do they face? What do they want from your product or service?

User stories should be specific, measurable, achievable, relevant and time-bound. They should also be written in a conversational tone to make them easy to understand.

Start by understanding your user’s problem. What does he or she need help with? What is the biggest challenge facing them?

User stories are one of the most important aspects of any software development project. They help to define the functionality of the software and provide a roadmap for the development team.

How do we write an effective user stories?

A User Story is an independent description of a feature or requirement that is to be implemented (i.e. Azure DevOps, JIRA, Rally, Trello, etc.). Scrum, Kanban, and Extreme Programming are all Agile frameworks that use user stories.

The Product Owner should prioritize user stories that are written as small, independently testable increments of the business need. The Scrum Team can contribute non-functional / technical stories while the Product Owners write functional user stories. Any non-functional user stories added to the Backlog, on the other hand, must be vetted and prioritized by the Product Owner. Overall, user stories should facilitate communication among the Product Owner, Scrum Team, and business groups (s).

Writing User Stories

The Product Owner breaks down groups of features / requirements, or Epics, into user stories during Sprint Grooming. The Scrum Team then uses Sprint Planning to estimate the level of effort required to complete a user story.

The user story is a brief, straightforward description of a feature or function written from the end user’s point of view:

I want [some goal, function] as a [type of user] so that [some reason].

As an example:

As a Leasing Specialist, I’d like to be able to upload an SF-81 document and attach it to my lease file.

When writing a user story, the following information is required:

• Description, or summary of the feature or requirement that meets the business need
• Acceptance criteria, or the actions necessary to call the user story “done,” in other words, meet the established Definition of Done (DoD)
• Any other items as identified by the team (e.g. Epic, Label, etc.) and within their tool of choice (e.g. Azure DevOps, JIRA, Rally, etc.),
• Most importantly, it should be:
  • independent
  • negotiable
  • valuable
  • estimable
  • small
  • testable

When the delivery increment is fully decomposed, user story independence is ensured; this allows for appropriate tasking, estimation, sizing, and testability of the effort. The Product Owner negotiates with the Scrum Team the prioritization of functionality against user needs, while the value of the user story drives its priority.

Furthermore, the acceptance criteria capture the testability of the user story; it should denote the “Who” (user), “What” (capability), and “Why” (outcome) of the increment.

However, writing good user stories can be a challenge. Here are a few tips to help you write effective user stories:

Start with the Users

A user story, as the name implies, describes how a customer or user uses a product. As a result, you should tell the stories from the user’s point of view. Furthermore, as the image below shows, user stories are especially useful for capturing a specific piece of functionality such as searching for a product or making a reservation.

Use Personas to Discover the Right Stories

Personas are an excellent way to capture your insights about users and customers. However, there is more to it: the persona goals assist you in discovering your stories. Simply ask yourself, “What functionality does the product need to provide to meet the personas’ goals?”

Write Stories Collaboratively

A user story is not a specification, but rather a tool for communication and collaboration. Never hand over a story to the development team. Instead, they should be part of a conversation: the product owner and the team should talk about the stories, or even better, write them together. This makes use of the team’s creativity and knowledge, which usually results in better user stories.

Keep your Stories Simple and Concise

Write your stories in an easy-to-understand manner. Keep them short and sweet. Avoid using ambiguous or confusing terms, and use active voice. Concentrate on what is important and leave out irrelevant information. The following template incorporates the user or customer as a persona into the story and emphasizes the benefit. Use the template as needed, but don’t feel obligated to use it. Experiment with various ways of writing your stories to figure out what works best for you and your team.

Start with Epics

Epics are large groups of coarse-grained user stories. Starting with epics allows you to sketch out the product’s functionality without getting bogged down in details. This is especially useful for new products and features: It allows you to capture the broad scope while also allowing you to learn more about the users and how to best meet their needs. It also cuts down on the time and effort required to incorporate new insights. When you have a lot of detailed stories, it can be difficult and time-consuming to relate any feedback to the appropriate stories.

Decompose your Stories until they are Ready

Break down your epic stories into smaller, more detailed stories until they are clear, feasible, and testable. Everyone should have a common understanding of the story’s meaning; the story should not be too long; and there must be an effective way to determine when the story is finished.

Add Acceptance Criteria

Remember to include acceptance criteria when decomposing epics into smaller stories. Acceptance criteria supplement the narrative by allowing you to describe the conditions that must be met in order for the story to be completed. The criteria enrich the story, make it more precise and testable, and ensure that it can be demoed or released to users and other stakeholders. For detailed stories, I like to use three to five criteria as a rule of thumb.

Use Paper Cards

Paper cards are not only inexpensive and simple to use. They promote collaboration by allowing everyone to take a card and jot down an idea. Cards can also be easily grouped on a table or wall to ensure consistency and completeness, as well as to visualize dependencies. Even if your stories are stored electronically, it is worthwhile to write new stories on paper cards.

Keep your Stories Visible and Accessible

Stories want to convey information. Don’t keep them on a network drive, the corporate intranet, or in a licensed tool. Put them up on the wall, for example, to make them visible. My Product Canvas is an excellent tool for discovering, visualizing, and managing your stories.

Don’t Solely Rely on User Stories

Writing user stories isn’t enough to create a great user experience (UX). Consider your product’s user journeys and interactions, visual design, and nonfunctional properties. This produces a comprehensive description that makes it easier to identify risks and assumptions, and it increases the likelihood of producing a product with the appropriate user experience.