10 Tips for Writing Good User Stories

Roman Pichler

Written by Roman Pichler

on Thursday 24th March 2016



User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But telling effective stories can be hard. The following ten tips help you create good stories.

435 Flares 435 Flares ×

1 Users Come First

As its name suggests, a user story describes how a customer or user employs the product; it is written from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific functionality, such as, searching for a product or making a booking. The following picture illustrates the relationship between the user, the story, and the product functionality (symbolised by the circle).


If you don’t know who the users and customers are and why they would want to use the product, then you should not write any user stories. Carry out the necessary user research first, for example, by observing and interviewing users. Otherwise, you take the risk of writing speculative stories that are based on beliefs and ideas—but not on data and empirical evidence.

2 Use Personas to Discover the Right Stories

A great technique to capture your insights about the users and customers is working with personas. Personas are fictional characters that are based on first-hand knowledge of the target group. They usually consist of a name and a picture; relevant characteristics, behaviours, and attitudes; and a goal. The goal is the benefit the persona wants to achieve, or the problem the character wants to see solved by using the product.

But there is more to it: The persona goals help you discover the right stories: Ask yourself what functionality the product should provide to meet the goals of the personas, as I explain in my post From Personas to User Stories. You can download a handy template to describe your personas from romanpichler.com/tools/persona-template.


3 Create Stories Collaboratively

A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to a development team. Instead, they should be embedded in a conversation: The product owner and the team should discuss the stories together.

You can take this further and write stories collaboratively, for instance, as part of your product backlog grooming process. This leverages the creativity and the knowledge of the team and results in better user stories.

If you can’t involve the development team in the user story work, then you should  consider using another, more formal technique to capture the product functionality, such as, use cases.


4 Keep your Stories Simple and Concise

Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out the rest. The template below puts the user or customer modelled as a persona into the story and makes its benefit explicit. It is based on by Rachel Davies’ popular template, but I have replaced user role with persona name to connect the story with the relevant persona.

As <persona> ,
I want <what?>
so that <why?>.

Use the template when it is helpful, but don’t feel obliged to always apply it. Experiment with different ways to write your stories to understand what works best for you and your team.

5 Start with Epics

An epic is a big, sketchy, coarse-grained story. It is typically broken into several user stories over time—leveraging the user feedback on early prototypes and product increments. You can think of it as a headline and placeholder for more detailed stories.

Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for describing new products and features: It allows you to capture the rough scope, and it buys you time to learn more about how to best address the needs of the users. It also reduces the time and effort required to integrate new insights. If you many detailed stories in the product backlog, then it’s often tricky and time-consuming to relate feedback to the appropriate stories and you have to be careful not to introduce inconsistencies.

6 Refine the Stories until They are Ready

Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. All development team members should have a shared understanding of the story’s meaning; the story should not too big and comfortably fir into a sprint, and there has to be an effective way to determine if the story is done.


7 Add Acceptance Criteria

As you break epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story, they make it testable, and they ensures that the story can be demoed or released to the users and other stakeholders. As a rule of thumb, I like to use three to five acceptance criteria for detailed stories.

8 Use Paper Cards

User stories emerged in Extreme Programming (XP), and the early XP literature talks about story cards rather than user stories. There is a simple reason: User stories were captured on paper cards. This approach provides three benefits: First, paper cards are cheap and easy to use. Second, they facilitate collaboration: Every one can take a card and jot down an idea. Third, cards can be easily grouped on the table or wall to check for consistency and completeness and to visualise dependencies.  Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories.

9 Keep your Stories Visible and Accessible

Stories want to communicate information. Therefore don’t hide them on a network drive, the corporate intranet jungle, or a licensed tool. Make them visible, for instance, by putting them up on the wall. This fosters collaboration, creates transparency, and makes it obvious when you add too many stories too quickly, as you quickly start  running out of wall space. A handy tool to discover, visualise, and manage your stories is my Product Canvas shown below.


10 Don’t Solely Rely on User Stories

Creating a great user experience (UX) requires more than user stories. User stories are helpful to capture product functionality, but they are not well suited to describe the user journeys and the visual design. Therefore complement user stories with other techniques, such as, story maps, workflow diagrams, storyboards, sketches, and mockups.

Additionally, user stories are not good capturing technical requirements. If you need to communicate what an architectural element like a component or service should do, then write technical stories or—which is my preference—use a modeling language like UML.

Finally, writing user stories is worthwhile when you develop software that’s likely to be reused. But if you want to quickly create a throwaway prototype or mockup to validate an idea, then writing stories may not be necessary. Remember: User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible—not to impose any overhead.

Learn More

Learn how to write effective user stories and improve your user story writing practice by attending my Writing Great User Stories Workshop. Reading my book Agile Product Management with Scrum will help you learn more about working with user stories in Scrum.


Article Name
10 Tips for Writing Good User Stories
Writing good user stories can be hard, but these ten tips will help you tell powerful stories.
Pichler Consulting Limited

Source: http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/

24 comments on “10 Tips for Writing Good User Stories

  1. Robert Wilson

    thanks for the post

  2. Agile Scout

    Thanks a lot for this. We featured this on our article today 🙂

  3. Prashant Khare

    Should the technical parts at the start of the project like setting up the environments, continuous integration, etc. be included as stories and also be estimated?

    • Roman Pichler

      Hi Prashant, Great question. I don’t capture work results that are necessary to create a successful product but are not meaningful to a customer or user as user stories. I simply add a card that says, for instance, “Install and configure CruiseControl so that software can be continuously integrated and tested”. The example is written similar to an epic. It uses a goal/benefit clause but has no user role or persona. I would suggest, however, to estimate the item, as the team will have to spend time and effort to get it done.

      Does this help?

      • RD

        Would you not write stories for environment setup etc and aim to complete those in sprint zero?

        • Roman Pichler

          No, I would not. If the work you mention is required, then I would describe the deliverables as simple statements, for instance, set up the development environment or choose a test automation tool, and add them to the product backlog. Customers and users don’t care about the environment setup. They want a product that does a great job for them 🙂

  4. Prashant Khare

    Thank you for very fast response! It is very helpful.

    Just one query though; when you say estimate the item – do you mean the relative estimation (Poker / T-shirt) ot the time estimation as done for the tasks / sub-tasks for the user stories?
    Thanks once again!

  5. Prashant Khare

    Thank you Roman! Very helpful thoughts…

  6. Lohic Beneyzet

    Thank you Roman for your posts. I’ve read this one and the linked one. Very useful! Especially the collaboration tip in writing user stories. I was struggling with how to deal with my role of Deputy Product Owner and now I think I’ve found the clue. Keep up the good job.

    • Roman Pichler

      Thanks for the feedback. Glad you’ve found my user story tips helpful!

  7. Thomas Hallett

    Useful tips, thanks.

  8. Matt Adams

    Thanks for the tips Roman. My company is currently in a transition period to Agile. In terms of ADAPT, we have the awareness, desire and the ability is coming fast – can you recommend a good book which focuses purely on writing user stories?


    • Roman Pichler

      Hi Matt, I recommend that you look at the following books:

      Mike Cohn. User Stories Applied
      Gojko Adzic and David Evans. Fifty Quick Ideas To Improve Your User Stories
      Jeff Patton. User Story Mapping

      • Matt Adams

        That’s great thanks Roman.

  9. Anuj Sharma

    If I as a BA getting user story from marketing, for a product meant for general public, is it a good way to write user story ” As a Marketing executive, I want customer to have ability to xxxx so that I or he/she can xxxxxx” . It will help in clearly understanding the owner of user story and objective.

    • Roman Pichler

      Hi Anuj, Thanks for your comment but I disagree with your recommendation. As the name suggests, user stories are primarily about the users and the customers. They should therefore feature in your stories and not internal stakeholders. I recommend that you formulate your stories “As , I want … so that …”.

  10. Bruce

    Great Post! Thanks for the advice and the templates. I’ll let you know how my project goes.

    • Roman Pichler

      Thanks for your feedback Bruce!

  11. Deepu Kumar Gouli

    Hi Roman,

    Thank you for such a detailed tips for writing user stories.
    I have query, I’m currently working in auto financial domain for the first time in my experience and finding it hard to create user stories for technical topics like Master Data Management ( Data Standardization, Data Historization.. etc). How to tackle this kind of situation. Can you please give some input to this.

    I see no simple which are maintained in past in these topics as well, The domain has data flow between different systems and creating business rules to standardize hundred of data field.

    It will be a great help if you give some input to me.

    Thank you in advance.

    Best Regards,
    Deepu Kumar Gouli

    • Roman Pichler

      Hi Deepu, Thanks for your comment. I don’t recommend writing user stories for technical topics like the ones you mentioned. User stories are great to describe end user functionality but not how a product or system works. If you want to capture architecture and design requirements, then I suggest that you use a modelling language like UML, which is better suited than natural language IMO. Hope this helps!

  12. Harsha

    Hi Roman,

    I was working in Operations for 10 years and now have joined as a Business Analyst in a bank for an Agile project. The Product Owner/SME has already written Epics and created a few product backlogs. He now wants me to write new backlogs relevant to the Epic and also write User Stories for each of the backlog items.He is knowledgeable but always short of time. How do I approach him with a set of questions for which I need his answers? I get totally blank and have no idea how I should proceed with writing new product backlog items and also writing User stories for each of these items. The Epic is at a very high level and I just have become clueless on how to proceed further. Can you pls guide me ?

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

435 Flares Twitter 81 Facebook 82 Google+ 67 LinkedIn 205 435 Flares ×