10 Tips for Writing Good User Stories

By Roman Pichler, 24th March 2016
Photo courtesy of Pexels

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 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 approach 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 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 too big and comfortably fit 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 will 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.

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

Learn More

Learn more about user stories with the following:

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

RSS Feed

64 comments on “10 Tips for Writing Good User Stories

  1. Rantanen, Veli-Matti

    As a electrical commissioning engineer, the critical things are the engine transient load test and engine load sharing, from the FAT, the engine transient load test was very good result, can we get the parameter of engine used for FAT test? How can we get the best engine load sharing?

    • Roman Pichler

      Hi Veli-Matti, Thanks for your comment. I am not sure I fully understand your question. Are you referring to a factory acceptance test? I’m afraid I am not a test expert.

  2. James Sessions

    Hi Roman,
    Can you tell me if the following can be categorised as a User Story or would it be correct to categorise it as acceptance criteria? Thank you for your help. Kind regards James Sessions.
    “As a Recruiting Manager I want to be able to input advert details into a recruitment form, so that a new post can be advertised”

    • John Ferguson Smart

      Hi James,

      So: “As a Recruiting Manager I want to be able to input advert details into a recruitment form, so that a new post can be advertised”

      I would argue that, no, you don’t want to input advert details (after all, typing is a pain), you want to post a new job advert. And why do you want to do that? I presume, to recruit more suitable candidates. So I would write this story like this:

      In order to attract more suitable clients
      As a Recruiting Manager
      I want to make the relevant details of a job accessible to potential and suitable candidates

  3. Hawwa

    Hi Roman, I’m currently part of a project with a group at University, and writing up the user stories.
    For the ‘so that..’ section of user stories, I was wondering what exactly its capturing.

    For example, some user stories directly relate to some sort of action such as:
    ‘As a Student,
    I want to be able to enrol to courses,
    so that I can access all content of that course’

    However, I find that some are not as ‘clear-cut’ in the so that..section. e.g. We have to include a feature where a Lecturer can include a map as part of a group meetup invite.
    ‘As a Lecturer,
    I can send a map in a group meetup invite
    so that…’ <- how can this directly relate to some sort of action?

    Could you provide any input as to how user stories can tackle the problem of capturing a functionality such as this?

    • Roman Pichler

      Thanks for your question, Hawwa. I find it helpful to derive user stories from personas and to link the “so that” part of a user story to the persona’s need–the main problem the persona wants to solve or the primary benefit the character wants to realise–and I’d recommend that you try this approach.

      I also find that stating a reason why it is necessary to provide the appropriate functionality works well for epics. As epics get broken them down into smaller, fine-grained stories, stating a reason can feel artificial: Users typically don’t want to access individual pieces of functionality, such as, set a password, but rather achieve a bigger goal like “personalise the app”. You therefore shouldn’t feel obliged to add a reason to all of your stories, particularly your smaller ones.

      Does this help?

      • Hawwa

        Thanks for the reply, your advice was quite helpful.

        How do you think UI requirements from the client are best captured? It’s tricky trying to pin down exact functionalities without it seeming too specific.

  4. Jyothis Narayanan

    Hi Roman,
    Thank You so much for such informative posts.
    One question I have is about the data validation on text fields.
    Do we need to cover them as part of acceptance criteria. If so, then is there any standard format that can be followed for specifying data validation details.
    Jyothis N

    • Roman Pichler

      Hi Jyothis,

      My preference is to create separate validation stories, particularly if the validation rules are not straightforward. If in doubt, decide together with the development team what top do.

      All the best!

  5. Vit

    What about some example user stories?

    • Roman Pichler

      Hi Vit, You can find user story examples in my other posts on user stories. I would hope, though, that my tips allow you to start telling stories about how users interact with your product. Remember: A user story is simply a story, no more and no less. And we all can tell stories.

  6. vicque l amos

    I’m new to agile methodology working on a new product using agile. I’m having a difficult time understanding what to do with technical stories. Initially, these were included as part of the functional story but the story point was 34 so split into a technical and functional story. However, the agile coach said there should be no technical story so now have to combined technical with the functional. Totally confused. My thought was to leave the functional and technical split and assign to an epic. your thoughts.

    • Roman Pichler

      Hi Vicque, Thanks for sharing your question. When splitting user stories, try to break them into smaller functional units, as I explain in my posts Epics and Ready Stories and Refining User Stories. Don’t make any assumptions about how the user stories will be implemented, for instance, which layers, components, or services will be affected. The development team should make those decisions, typically in the sprint planning meeting. Hope this helps!

  7. gapsel

    I’m learning writing user stories. This help much. Thank you.

  8. Lloyd Lawrence

    Hi Roman,

    Thanks for the very informative article. I work in the IT support field (general support, not specific to application support), and have been investigating the possibility of using User Stories for defining issues or experiences that users go through in their IT working environment. Do you think User Stories are adaptable to a scenario such as this, eg:
    Joe Bloggs is an Engineer. Joe needs to be able to open, fill and sign PDF files in order to approve work orders. Joe often experiences freezing or crashing of the PDF file while trying to fill one out.

    • Roman Pichler

      Hi Lloyd,

      Thanks for your question. You can certainly use user stories to describe the requirements stated in your sample scenario. If you want to describe the entire workflow or interaction, however, I recommend using a scenario, storyboard, or story map, see my post Agile Scenarios and Storyboards. Hope this helps!

  9. Raviavi

    Dear Roman,

    Could you please give atleast one example of an Epic ?
    Do they follow the same format as the smaller User Stories, or are they in a different format ?
    Is it for example ok to have an Epic as follows : –
    As a [ Manager ] I want to [ view monthly reports ] so that I can [ manage my branch well ]
    Or is it traditionally written in a different way ?

    • Roman Pichler

      Thanks for asking the question, Raviavi. Epics are simply big, coarse-grained user stories. They are typically so large that they cannot be implemented in one sprint and therefore have to be eventually broken down into smaller stories. You can write epics using the format stated in tip number four (if that works for you) but you don’t have to. There is no one right way to formulate a story. What matters is that the development team understands the epic or user story. Your example sounds like a nice epic. I would recommend, though, that you make the goal more specific: State how viewing reports helps managers do a good job. You can find more information on epics together with sample epics in my post Epics and Ready Stories. Hope this helps!

      • Raviavi Read more http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/

        Thanks very much Roman.

  10. Randy

    we take a business need (user story/feature) and through conversations we design the solution and create stories for that work. All this prior to starting the sprint for that bus need? Is that correct?

    • Roman Pichler

      Thanks for your question, Randy. A business need or goal is distinct from a user story or feature description. A business need might be to acquire new customers, generate revenue, or increase conversion. A user story captures how someone interacts with the product and uses a price of functionality. I recommend that you determine the business need and the product’s value proposition before you create any user stories. Hope this helps!

  11. Randy r

    With regards to team understanding of stories. I’m being told that the team gets a business need or story. They size it and then during the sprint is the time the design a solution for implementing the story. Seems the conversation needs to happen sooner. How can you size it without some idea of WHAT the solution will be. Is that correct?


    • Roman Pichler

      Hi Randy,

      User stories are commonly sized (or estimated) for three reasons:

      1. Help prioritise the product backlog (by performing a cost-benefit analysis).
      2. Track the projects progress, for instance, by using a release burndown chart.
      3. Ensure that the sprint goal is realistic and help the development team pull the right amount of work into the sprint (assuming that the team uses velocity-based iteration planning).

      I recommend that you are clear on why you size stories to choose when you should so it.

      The last point in time for the user stories conversation to happen is the sprint planning. But I would recommend including the team or some team members in the product backlog management work (aka grooming or refinement), as I discuss in my post Grooming the Product Backlog.

      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 ?

  13. 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!

  14. 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!

  15. 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 …”.

  16. 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.

  17. Thomas Hallett

    Useful tips, thanks.

  18. 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!

  19. Prashant Khare

    Thank you Roman! Very helpful thoughts…

  20. 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!

  21. 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 🙂

  22. Agile Scout

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

  23. Robert Wilson

    thanks for the post

Leave a Reply

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