Photo courtesy of Pexels

10 Tips for Writing Good User Stories

Published on 24th March 2016

Last Updated on February 13, 2020

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.

1 Users Come First

As its name suggests, a user story describes how a customer or user employs the product; it is told 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.

User Story Overview


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.

From Persona to User Story


3 Create Stories Collaboratively

User stories are intended as a lightweight technique that allows you to move fast. They are not a specification, but a 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. This allows you to capture only the minimum amount of information, reduce overhead, and accelerate delivery.

You can take this approach further and write stories collaboratively 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.

User Story Collaboration


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 a 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 have many detailed stories in the product backlog, then it’s often tricky and time-consuming to relate feedback to the appropriate items and it carries the risk of introducing 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 be too big and comfortably fit into a sprint; and there has to be an effective way to determine if the story is done.

Epic versus user story


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 will start  running out of wall space. A handy tool to discover, visualise, and manage your stories is my Product Canvas shown below.

Sample Product Canvas


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.

Post a Comment or Ask a Question

106 Comments

  • Nermin Elsayed says:

    Hello Roman,
    Thank you so much for this post. When do you advise to write stories? In my understanding, writing stories is part of the grooming phase, prior to planning a sprint. As you mentioned in one of your answers, that last point in time to discuss a story is the sprint planning.

    Hence when we groom stories for a scaled agile release, then the stories should be estimated and groomed before planning day of the release. However I see many coaches advising to enter planning day without predefined stories. Eventually we end up with delayed testing, for weeks, as team is still refining the stories during the sprints.

    – Can you advise about the realistic timeline to start defining the stories and it’s according acceptance criteria?
    – Do you agree that entering a scaled release planning day with predefined stories is a Product Owner sin of pride?
    – What do you advise product owners who recently switched from scrum to scaled agile releases and have to prepare for planning day?

    Thanks in advance.

  • Siddharth says:

    Hey Roman, extremely helpful. My question is about technical story? How to write them and what is the involvement of product owner? How does one identify acceptance criteria for technical stories?

    • Roman Pichler says:

      Thanks for sharing your feedback and question Siddarth. By definition, user stories describe end user requirements. You can, of course, tell stories about how a product is built using technical stories. But I find that natural language is not well suited to capture technical requirements, and I prefer to work with a modelling language like UML (Unified Modeling Language). If you manage a technical product like a software platform, you should have the necessary technical knowledge to capture the requirements for this product. Hope this answer is helpful.

  • Jaya says:

    Hello Roman, Thanks for the insightful article. Apart from user stories we do perform common activities on an epic like Regression, UAT Data Creation and Support, Go-Live Prep & Go-Live. As these activities take up the team’s capacity, we record this in JIRA and is part of the sprint for visibility purposes. What’s the best practise around this? Can these sit as enabler stories/tasks within the sprint?

  • Shru says:

    Hi Roman,

    This is an excellent article. I have just started working as a BA with no prior experience and this gives me a fair idea of what I should keep in mind while grooming the backlog. I have a doubt though (I am sorry if this comment turns out to be too long). This is my first project with the organization and the users want us to build an app for one of their manual processes. I have already written 8 placeholder user stories . The next expectation is to add to these user stories (add few more lines to the description, add acceptance criteria etc). So for instance, one of the user stories is “As a *** user , I want the application to have the below fields “. Now within this user story, in the description I have listed all the fields (compulsory and optional) that the user wishes to have within the new app. My doubt really is – what more can I add to the description? What can the acceptance criteria be? I have no proper reference , so it would be nice if you could help me with this so I can work on the other 7 user stories also based on the pointers you mention. Thanks a million in advance !

    Best regards,
    Shru

    • Roman Pichler says:

      Thanks for sharing your feedback and question Shru. I recommend involving the development team or at least some of its members in the process of discovering and refining user stories. This will help you get the level of detail right: If the stories don’t contain enough information, the dev team is likely to tell you. The same is true when you add too much detail to the stories. Just as a side note, I would keep your stories free of user interface information and capture the latter separately by using, for example, a sketch or mockup, see my articles User Stories are Not Enough for a Great User Experience and Agile User Interface Design. Hope this helps!

  • Dev says:

    A very good article. I really liked the way you give response to all the queries and share links for the answers.

    Great work !!!

  • Sarkhan Hajiyev says:

    Than you so much Roman for article, it’s practical and useful. If you don’t mind I want to use it in my presentation for Product Owners in our company sharing the source of course 🙂
    Have a good day!

  • Charuta Bapat says:

    I work as a product manager and developing a new product. I would like to know about Product Manager’s role in epics, features and user stories.

  • Haseen Libas says:

    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.

  • bliss says:

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

  • Ivan Manalu says:

    Thank you very much for your article. It’s very helpful to clearly understand how to write good user stories.

  • Melike says:

    Thank you for your help Roman 🙂 Your answer makes a lot of sense.

  • Melike says:

    Hello Roman,

    Really nice article. I have a question writing “independent” user stories. When I think of independent, I tend to define stories as atomic as I can. I wonder if this is a good approach or if I’m flooding the backlog with semi-duplicate stories.

    Let’s say I have a functionality on UI, which is for processing files in a certain way. And I have exactly the same functionality on another screen, which is for processing database tables.

    The question is; shall I create separate stories for files and tables in that case? Recently I had a discussion about this with a fellow product owner and he said that it’s better if I reuse the stories which I added for file processing. It feels wrong to reuse the existing stories.

    Thank you!

    • Roman Pichler says:

      Hi Melike,

      Thank you for your feedback. Good to hear that you like my article. Before I answer your question, I’d like to briefly explain why independent user stories can be helpful: They allow us to prioritise the product backlog without having to account for inter-story dependencies. Otherwise, if story A is dependent on story B, we have to implement (parts of) story B together with story, no matter if that’s helpful or not.

      Regarding your question, if a user can process a file and the individual can work on a database table, then I would be inclined to write two user stories. Technically, the stories may be implemented largely in the same way. But this should not matter when it comes to story writing. Remember: A user story should always describe what a user can do with a product, not how functionality is implemented. If you decide to create two stories and if these stories will be implemented in a similar way, then this does not necessarily create a new dependency. But it might result in a smaller effort estimate of the second story, assuming that the code written to implement the first story can be (partially) reused in the second one.

      Does this help?

  • Venkat says:

    Hi Roman,

    Can you please guide on achieving Independence and Value during the splitting exercise for a workflow of a Bus Ticket booking? The workflow steps may include following :

    user submitting basic personal details
    user choosing source and destination
    user choosing seats
    user making payment

    In the above , some of the steps such as user choosing seats, user submitting personal details, user making payment etc, are not “valuable” to end user on their own, although they can be independently tested using mock database objects or hard-coded pre-requisites, etc. Can you please kindly guide on achieving “independent” and “valuable” through split of user stories for above workflow. Also, releasing to production of any o these individual steps (split user stories) may not be valuable to end user, until the whole user journey (of complete bus ticket booking) is made available to end user. Can you please kindly guide for approaching the above scenario?

    • Roman Pichler says:

      Hi Venkat,

      Thank you for sharing your question. To answer your question, I think it is helpful to briefly reflect what “independent” and “valuable” mean. The idea that user stories should be independent and valuable was first proposed by Bill Wake. An independent story is easier to prioritise, and it can be implemented and released on its own. Valuable, as defined by Bill Wake, means that a story is valuable to the customer; it offers end-user functionality and typically results in implementing a vertical slice rather than a service, component, or layer. With this in mind, you may want to capture the overall user journey, for example, as a scenario and consider describing the steps as epics. Next, derive detailed stories from the epics ensuring that each story offers value to users or customers. As your stories become fine-grained, you may find that some of them are no longer independent. That’s OK in my mind. Independence, I find, is best applied to larger stories and epics.

      When it comes to releasing functionality, consider employing a product roadmap in combination with a release burn-down chart or cumulative workflow diagram. There is nothing wrong with batching up functionality for, say, two to three month in order to have a bigger release, it that’s helpful for the users and business.

      Hope this helps!

  • JR says:

    Hi Roman,

    I am an IT BA on a team that is working in an agile type requirements gathering process. We have some trouble communicating and some team members do not get a long. Do you have an tips for successful requirements gathering process for a team who struggles with communication?

    • Roman Pichler says:

      Hi JR,

      Thanks for sharing your question. It seems to that you are facing two challenges: gathering requirements and helping the team members effectively work together. The latter is something your Scrum Master should help the team address, see my article “Product Leadership in Scrum”. With regards to the first challenge, I recommend deriving epics and user stories from user/persona goals as I describe in the article above. Then choose a goal for the first sprint and expose the resulting product increment to some of the users. Listen to their feedback and use your insights to make the right product decisions and adapt the product backlog accordingly. For more information, please take a look at my article “Grooming the Product Backlog”.

      Hope this helps!

  • jane says:

    Hi Roman,
    I have a question for you , we doing a homework about user story,
    my question is user stroies are written for whole system or part of the system ?

  • Maciej Lewandowski says:

    Hello. Do you agree that not the form of the user story is most important but the expressed value?

    • Absolutely Maciej. As I say in the article: “Use the [user story] 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.” There is no one right way to tell a story.

  • Tony Bresse says:

    Hi Roman
    In your final statement you wrote
    “Remember: User stories are not about documenting requirements”

    As a certified scrum Master and Product Owner, I always considered User Stories as the new structured way of documenting functional requirements.

    And the User Story backlog is the replacement of the traditional BRD Business Requirements Document that listed the functional requirements.

    If user stories are not requirements, then how are the requirements represented in the Agile framework? And what do they look like?

    • Hi Tony,

      Thank you for sharing your question. A traditional functional requirement is replaced by one or more user stories plus a conversation between the product owner and development team. In order to effectively apply user stories, product owner and dev team must discuss product functionality together on a regular basis, for example, as part of the product backlog grooming or refinement work. If this doesn’t work for you, then I recommend experimenting with use cases, see my article “User Stories or Use Cases?“.

      Hope this helps!

  • Ondrej says:

    Hi Roman,

    I need to implement a fraud detection solution into my digital product. This is solely just for the business to evaluate if the user is a human being or a bot.

    So is it bad to write story of “As business I want to have a fraud detection implemented so I can lower the risks in the business process”? Is user really just the one who is using the frontend of the app (customer)? Isn’t it the same as stakeholder instead that means any affected party? I mean.. Users of some features (story) are sometimes someone else then a user of the whole application, right? Other example – I need to upgrade to a newest technology so it’s easier for me to develop faster and more precise. User story of “As developer I want to have XX technology implemented so I can develop faster and more precise” is not good then?

    I think that it does not really matter who is the user but the fact that group of people will really use the object of that story. Am I wrong? Purpose of the user story is to tell a user’s story so the developer or whoever for who the task is intended understands a view of that user. I find it not beneficially to try to write every story from the view of the customer as it is not describing the reality then.

    I would really appreciate your opinion here as I respect you a lot but in the same time I believe this rule “user = customer / ending user” is contra-beneficiary.

    • Thanks for sharing your question Ondrej. User stories are just a simple technique to help you describe a product from the perspective of a user, customer, administrator, or another role. It’s entirely up to you, of course, if and how you use the technique.

      Having said that, I find it beneficial to carefully consider who will benefit from a product and describe the individuals using personas. This avoids a solution-centric mindset where we worry more about how to build the product rather than for who and why.

      When it comes to capturing development work, I would simply add an item to the product backlog that states “Investigation of new tools and technologies to increase development productivity”. Don’t feel obliged to describe all product backlog items as (user) stories.

      Hope this helps!

  • Costas says:

    Thank you Roman for all the helpful information on your site!

    What would you do if, due to certain system components being unavailable, the DEV team requests stories that describe slices of user functionality to be broken down further at system component level?
    For example, AS a buyer, I WANT to see the total price for the selected product, SO THAT I can decide if I want to buy it. Due to commercial reasons, and for the next few sprints, the DEV team has no code access to the back-end system that will process the logic to derive the price. What we did in this case is to leave the story as-is with the prefix [Front-end]. Without a real calculation in place the user will see a dummy price and the story will pass. We created an identical story with the prefix [Back-end] which remained in the backlog until the calculation logic could be built.

    What are your thoughts? How would you handle this?

    Thank you

    • Hi Costas,

      Thanks for your feedback and sharing your question. Sounds like you found a solution that works for you, which is great. An alternative way to handle the issue is to delay the implementation of the story until you have gained access to the back-end system. Personally, I would prefer this option to avoid splitting the story by architecture and effectively ending up with a partially implemented one. This might also help highlight the real issue: the inability to access the back-end system. Hope this helps!

  • Lora says:

    Great post. Added it to the Awesome List of Agile Software Development https://github.com/lorabv/awesome-agile-software-development/blob/master/User-Stories.md

  • Alan says:

    Hi Roman,
    We have engineers who document the technical solution they’re going to implement in the story description. It seems wrong, but where else would they document it?

    • Hi Alan,

      I recommend keeping user stories free from implementation details. The stories should capture how users employ product functionality, not how the solution is built. I’ve found it helpful to capture technical decisions in form of UML diagrams like component, activity, and sequence diagrams. Additionally, your dev team may want to use an overall architecture model that documents key decisions affecting the entire solution. Scott Ambler has done a lot of good work on agile modelling techniques, and I suggest that you take a look at his site http://agilemodeling.com.

      Hope this helps!

  • Hi Roman. Thanks for your articles and blog!

    But I have a question. You wrote “Stories should never be handed off to a development team”. But here http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/ mentioned that “[story card] often handed to the programmers”.

    We are now doing exactly this: passing user stories to devs, then devs discuss them and create issues.

    Can you please explain why do you think stories should not be passed to devs?

  • Sergey says:

    Hi, Roman, thank you for the excellent post. I have a question related to the number “10 Don’t Solely Rely on User Stories” I have the following architecture: Portal for schools to post jobs, a separate Portal for candidates to apply for a job, a CRM system as a backend system to manage/mediate a process between Schools and Candidates. First question, should we have user stories across all three types of users? What would be the best artefact to cross reference these user stories? Would you recommend process maps, customer journey or something else? I would appreciate you input.

    • Thanks for your feedback and question, Sergey. I recommend that you write user stories for the school employees (presumably the head teachers) and the job seekers. Capture your software architecture decisions in a architecture model using, for instance, UML. User stories describe functionality from an end user’s perspective and should be free from architecture and technology concerns. To put it differently, user stories describe the what–what a product should do–and not the how–how the product is built. Does this help?

      • Sergey says:

        Thank you, Roman.
        What about CRM users? Do we need to have user stories for them? They are basically managing processes needed to support both, schools and candidates. They are using out of the shelf solution which we customise. I think process maps (with swimlane) is the medium to link different user groups user stories together in the end to end flow. What do you think?

        • Hi Sergey, Sounds like you should write stories for the CRM users, assuming that they directly interact with the system. You may find it helpful, though, to take a step back, determine the users and customers of the product, and create personas before you write more user stories. Good luck!

  • Diogo says:

    Hi. Very good tutorial on writing user stories.
    I have a question though. As a web development intern I was given the task to create the user stories of a tool that will possibly be implemented in the company, for our own use. I say possibly, because there already exists a tool that apparently does what we need, but seems to be harder to integrate and customize for our needs. Being part of the development team I am basically writing my own experiences on using the existing tool, so what should be my approach in writing the user stories? Something like: As a business analyst, I would like to (what) so that I will be able to (why). As simple as that? As the project progresses and as part of the customization, I assume that existing functionalities will be suppressed and not be implemented and new one possibly created to fulfill our needs. Are there any tricks and tips I should know or pitfalls I should avoid when creating these user stories? I also assume that even being a developer, I should take the hat of the company business analysts or managers, as to think as they would when using the tool to be developed. Am I right?
    Thank you for your post!

    • Hi Diogo,

      Thanks for your feedback and for sharing your question. No matter what product you develop, always starts with the users and the value the product should create for them. In your case, I would ask what benefit the tool should offer or which problem it should address, and who the users are.

      Once you can confidently answer these questions, create personas and get together with the people who should build the tool and capture the key pieces of functionality as epics. My article From Personas to User Stories explains how you can do this.

      Good luck!

  • Muhammad says:

    How would you write a user story from a user prospective if the story is to redesign the page cosmetically. The story has been instigated by the content designer. I was thinking of below but when you say think from user prospective then it would be wrong.

    As a content designer
    I want to improve the layout of the xxxxxx homepage
    So that I can enrich the customer experience with quality visual designs