User Stories in Product Management

Unlocking the Power of User Stories: Driving Conversations and Contextual Clarity 

User stories are a fundamental tool in agile development, but their true power lies not just in how they are written but in the conversations they inspire and the context they provide. 

Many years ago, I was speaking with a fellow product manager about Product Management practices at her organization, and she related a story to me about User Stories.  The developers in her company were complaining that the Product Managers were not writing good user stories.  They hired Kent Beck to teach the team how to write better User Stories.  Kent Beck kicked off the session by saying something like, “A User Story is a reminder or promise to have a conversation”.  And from there, he spent the rest of the time helping the team to have better conversations around the User Stories.

The Power of Conversation  

The written user story itself is not the end goal; rather, it serves as a starting point for discussions with the broader team. Used correctly, the story is a tool to build a shared understanding of why focusing on this use case is important to the customer and what the company may need to develop. Through these conversations, teams can clarify customer understanding, align objectives and the problem to be solved, and iteratively arrive at a more valuable solution.  These conversations help uncover nuances, address potential issues early, and clarify the desired outcome. By emphasizing communication, user stories become a cornerstone of successful product development

If you don’t take anything else away from this article, remember this – The user story is incomplete until you have discussions with the product development team.

Don’t start development work on User Stories without first having conversations about the User Stories between the Product Manager or Product Owner (Product Manager vs. Product Owner — You Asked, We Answered – Productside ) and the development team! 

The starting point for great user stories is customer understanding  

Instead of making up requirements about what we think the customer wants to do (yes, we have all done that 😉), we need to begin with a clear understanding of the customer need, the Job they are trying to accomplish, and what success looks like for them. The only way we can achieve that is by having conversations with our customers and the key users of the product and this requires us to conduct Voice-of-the-Customer (VOC) Research (For expert guidance, download our Voice of the Customer Template here).

Sharing context around the user story 

While a user story can stand alone in terms of development work, it often lacks full context without a broader understanding of the problem it addresses and for whom. After you have completed VOC research, you could start writing dozens of User Stories, but this is not the best tactic. To get the best development results, we want to first communicate the context of the user stories to the development team.   Without this context, developers may ship a feature that meets the base requirement but does not deliver a great experience to the user. 

Three tools that I have found most useful to communicate the context of the user stories are: 

• User Personas 

• Problem Statements 

• Story Mapping 

User Personas:  This is a semi-fictional character based on research that represents the dominant user personas of your product.  Personas help teams empathize with users.  (How to Create Personas for Your Next Product — and Why It Matters – Productside) 

Problem Statements: A high-level view of the issues that need solving. Problem statements focus user stories on solving specific aspects of a broader problem and ensure they align with the overall project goals. (How to Write a Problem Statement | Productside) 

Story Mapping: This technique involves breaking down larger user problems into smaller, more manageable user stories. Story mapping allows teams to visualize the user journey, identify gaps across it, and ensure that all aspects of a problem are addressed. It also helps in prioritizing tasks and creating a cohesive approach to development. (The New User Story Backlog is a Map – We help you create successful product culture and process (jpattonassociates.com))

Writing a User Story 

The standard template for a well-crafted user story follows the model:  

As a [type of user/persona],  

I want to [an action]  

so that I [a benefit/a value].  

This format keeps the focus on the user and their needs. Using this format, you clearly identify who is interacting with your product, identify the action, task or goal that the user is trying to accomplish, and why being able to do this is important to them. 

Some guidelines to consider for user stories that will drive the best conversations 

1. Be Specific: Clearly define the user and their goal. Vague stories lead to confusion, misinterpretation, and can be overwhelming in scope. 

2. Keep it Concise: A user story should be brief but convey the essential information.  Remember, too much detail may make the development team feel constrained in the solution that they can develop, so keep things informative but not prescriptive. 

3. Focus on Value: Always highlight the benefit or value that the user will gain. This keeps the team aligned on the end goal of what the user is trying to accomplish 

Writing Acceptance Criteria 

Acceptance criteria are the conditions that a user story must meet to be considered complete.   They are less about the user and more about the feature. Acceptance criteria provide clear, testable requirements such that the final product meets the user’s needs.  

There are multiple formats for writing acceptance criteria that generally fall under Scenario-Oriented and Rule Oriented.   

Scenario-Oriented Acceptance Criteria: These criteria describe specific user scenarios or situations, defining the conditions, the actions taken and the expected outcomes for each scenario. 

Rule-Oriented Acceptance Criteria: These criteria list specific rules or conditions that the system must satisfy. Each rule is a discrete requirement that tests whether functionality meets all the predefined standards or business rules. 

 Choose the format that applies best to your context as an organization and for a specific User Story.  (What Is Acceptance Criteria: Definition, How-Tos, And Tips In 2024 (mambo.io))  

When writing acceptance criteria, consider the following: 

1. Be Clear and Precise: Each criterion should be unambiguous and easy to understand. 

2. Testable: Ensure that criteria can be tested and measured. This helps in verifying that the story has been implemented correctly. 

3. Comprehensive: Cover all aspects of the story to avoid any gaps in functionality. 

When to Break Down User Stories  

Not all user stories are created equal. Some may be too large or complex and need to be broken down into smaller, more manageable stories. Here’s how to determine if a user story needs to be detailed more or divided: 

1. If a story seems too broad and the scope is not clear or the development work is more than a single iteration, it might need to be split into multiple stories that address different parts of the user’s goal. 

2. If the acceptance criteria can be prioritized differently, such that some elements of the acceptance criteria are must haves and others are nice-to-haves or refinement of the user experience, you might want to break this into multiple User Stories with different levels of prioritization. 

While these are guidelines, the most important aspect of User Stories and Acceptance Criteria is that you have created strong understanding between the Product Manager/Owner and the development team such that they understand it well enough to deliver a capability that addresses the need of the customer.  And you’ll only achieve this by driving great conversations. 

Driving Effective Conversations  

Early in my Product Management career, I felt offended when I wrote requirements and User Stories, and the development team didn’t understand them and started asking many different questions.  I quickly learned that writing the perfect User Story is a fantasy and that the questions from other stakeholders created a better User Story and enhanced the understanding of what would be valuable to the customer.  

Reviewing user stories is a critical step in ensuring that they are well-understood and actionable. Here are some tips for driving effective conversations during this review process: 

1. Engage Multiple Stakeholders: Include various stakeholders involved in the project to get diverse perspectives and insights. 

2. Welcome Questions: Encourage questions to clarify any ambiguities and ensure a shared understanding.  

3. Iterate and Improve: Use feedback from these conversations to refine and improve the user stories continuously. 

Get to Writing!   

A good user story is more than just a requirement; it is a conversation starter that drives clarity and alignment within the product team. By providing context through personas, problem statements and story mapping, writing clear and concise stories, defining precise acceptance criteria, and knowing when to break down larger stories, teams can create a strong foundation for successful development. Ultimately, the key to a good user story lies in fostering effective communication, ensuring that everyone understands the user’s needs and goals. 

ABOUT THE AUTHOR

Tom Evans

Principal Consultant and Trainer