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.
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.
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 refinement process. This leverages the creativity and 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, for example, use cases.
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.
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.
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.
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, make it testable, and ensure 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.
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 used to be 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. If using paper cards is not an option for you, then choose a tool that allows you to create virtual cards, as Trello does, for example.
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.
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 for capturing technical requirements. If you need to describe what an architectural element like a component or service should do, then write technical stories or—which is my preference—use a modelling language like UML.
Finally, writing user stories is worthwhile when you develop software that’s likely to be used. But if you want to quickly create a throwaway prototype or mockup to validate an idea, then writing stories may not be necessary. Instead, it might be better to cocreate the prototype. 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.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
Thank you for sharing.
You're welcome Nicole.
Hi, Can you please answer the following two questions for me: 'How would you describe the role of a Business Analyst within a multi-disciplinary Scrum Team'? Secondly, how do you manage a requirement? Thank you.
Hi Clement, Thanks for sharing your questions. You can find my advice on applying the business analyst role in Scrum in the article Business Analysts in Scrum. How you best manage requirements will depend on the process you use. If you apply Scrum, then you may want to read my articles 5 Tips for Stocking the Product Backlog and The Product Backlog Refinement Steps. Hope this helps!
Thanks for a great post Roman, it has stood up well after all this time!
A couple of questions around user stories that you might be able to help me with:
1. I am trying to make use of user stories in the context of an ERP system selection, i.e., not a development, but the acquisition of an existing system. These systems can be configured, but we are trying to avoid the cost and lock-in of customising vendor code to bend these systems to do things in ways that are not part of the systems out of the box. Do you think it practical to specify requirements based on User Stories in this way for a selection exercise?
2. How should we handle 'overshoot' with the user stories (either in a selection or a development)? How do we ensure the user stories aren't asking for a Ferrari when a Fiat meets the needs of the business?
Thanks,
Sim Teo
Thanks for sharing your feedback and question Sim. If you want to capture how end users will use the ERP functionality, then user stories should be well suited. Bear in mind, though, that a story does not specify a requirement--at least not on its own. It has to be complemented by a conversation. Understanding the users' needs and creating personas can help you discover the right user stories, as I mention in the article. Additionally, you will benefit from working with a validated product strategy and an actionable product roadmap. Hope this helps!
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.
Thanks for your feedback and questions Nermin. Regarding a timeline for grooming/refinement, please take a look at my article "When Should Porduct backlog Refinement Take Place?" I am afraid I can't answer your questions two and three, as I am not a SAFe expert. I suggest that you refer to the SAFe documentation. Hope this helps!
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?
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.
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?
Thanks for sharing your question Jaya. The activities you mentioned should be covered by the Definition of Done and they may result in tasks captured on the sprint backlog, assuming the development teams uses capacity-driven sprint planning. Hope this helps!
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
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!
A very good article. I really liked the way you give response to all the queries and share links for the answers.
Great work !!!
Thank you for your feedback!
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!
Thanks for the feedback and good luck with your presentation!
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.
Thanks for sharing your question Charuta. The following two articles should help you answer your question: Refining the Product Backlog and Scaling the Product Owner Role.