How to Write User Stories: The Ultimate Guide

User Stories are more than tasks or requirements. They are narratives that foster collaboration, guide development and drive meaningful outcomes.

Hey, Paweł here. Welcome to the freemium archived edition of The Product Compass.

Every Saturday, I share actionable tips and resources for PMs.

Here are some posts you might have recently missed:

1. [Free] What is Product Management?

2. [Free] How to Become a Product Manager?

3. [Premium] User Interviews: The Ultimate Guide to Research Interviews

4. [Premium] Product Vision vs Strategy vs Goals vs Roadmap: The Advanced Edition

Subscribe now, if you haven’t already, for the full experience:

---

How to Write User Stories: The Ultimate Guide

I haven't covered Agile and Scrum topics in this newsletter so far.

But it’s hard to ignore that:

• Most of us work in one of the Agile frameworks.

• Many Product Managers use tools like Jira daily.

• Mistakes can result in waste, delays, and team members disengaged at work.

These are the basics you must get right as a PM.

So, in today’s newsletter, as one of the ~400 PSPO III, I'd like to explain everything you need to know about User Stories:

1. What Are User Stories?

2. How to Write Good User Stories?

3. 🔒 How to Split User Stories: An Introduction

4. 🔒 9 Proven Tactics to Split User Stories

5. 🔒 User Stories vs Job Stories

6. 🔒 8 Common Mistakes to Avoid

1. What Are User Stories?

A User Story is one of the formats you can use to create a Product Backlog item.

While not the official part of the Scrum framework, they are the most common approach to describe the work that needs to be done in your product.

A User Story is written from the perspective of a user who wants to derive value from the product. It should focus on the user's desired outcomes and be embedded in the context where the user seeks value from the product.

User Story format and examples

The basic format of a User Story is simple:

WHO: As a [user type]
WHAT: I want [action to perform]
WHY: So that [the desired outcome]

See the User Stories examples on the cards below:

User Stories examples

A prerequisite to working with User Stories is understanding the users, ideally segmented by their needs and desired outcomes. For more information, see:

• How to Achieve Product-Market Fit? Part I: Market and Value Proposition, point 3

• Jobs-to-be-Done Masterclass with Tony Ulwick and Sabeen Sattar

---

2. How to Write Good User Stories?

2.1 Start with validated product ideas

Where do User Stories come from?

It’s not about the Product Manager who comes up with brilliant ideas or stakeholders submitting their feature requests.

Creating User Stories must result from Product Discovery, which allows the product team to discover opportunities, brainstorm ideas, and address the critical risks before the implementation.

For more information, see the newly refreshed, comprehensive summary of what Product Discovery is (no paywall):

What Is Product Discovery? Product Discovery 101

2.2 The 3C’s of User Stories

The 3 C's of User Stories are Card, Conversation, and Confirmation.

They are essential for writing a good User Story:

Card

Those are the cards I previously presented, explaining WHO, WHAT, and WHY. Although they once were physical cards, you're more likely to create User Stories in tools like Jira today.

Conversation

Rather than creating a detailed specification, discuss the reasoning behind the User Story with the whole product team and stakeholders.

It’s also essential for everyone to understand not just how the User Story will benefit the users but also how it will contribute to the Product Outcome (or Product Goal in Scrum) and how it aligns with your product strategy.

This empowers others to make informed, autonomous decisions without micro-management.

Confirmation

Confirmation refers to the Acceptance Criteria that should be fulfilled to ensure the requirements have been met and delivered correctly. It's typically a concise checklist, not a list of detailed test cases.

2.3 The INVEST User Stories

INVEST is an acronym representing the essential qualities of well-written User Stories:

• Independent: Each User Story should be self-contained and not depend on other stories.

• Negotiable: The details of the User Story can be discussed and negotiated with the team and the stakeholders.

• Valuable: The User Story delivers value to the user.

• Estimable: It should be possible to estimate the effort required to complete the User Story.

• Small: User Stories should be small enough to be completed within a single iteration. If you do not work in iterations, you might assume 2-4 weeks as the rule of thumb.

• Testable: There are clear criteria to determine if the story has been successfully implemented.

While those qualities are highly desirable, do not obsess over this acronym. In practice, it’s virtually impossible to keep every User Story independent and valuable for the user.

2.4 The example User Story

In the example User Story below:

• I suggested a title, “Recently viewed section.” You wouldn't want to copy the Card directly into the title, as it would be unreadable.

• I linked to a previously created and validated design.

• I suggested you the possibility of adding selected details like:

  • Interactions if the design is not self-explanatory.

  • Business rules that might be summarized, e.g., as a table.

• I defined the acceptance criteria as a brief checklist, not a list of test cases.

User Story Example

2.5 Who writes User Stories, and how much time does it take?

Don’t even get me started on Product Owners “accountable for effective Product Backlog management” ;)

First, there is no such job title as a Product Owner. The Product Manager best fulfills this accountability.

Second, managing a Product Backlog should be a collective effort because you can succeed only as a team.

Everyone on the team should feel a sense of ownership of the product. So, encourage your team to participate actively in creating User Stories and refining their details.

As a rule of thumb, managing the Product Backlog shouldn't take you more than 4-8 hours a week. Your key focus should be on discovering what to build together with the The Product Trio, communicating the strategic context, and aligning with the stakeholders.

Not creating documentation.

---

3. How to Split User Stories: An Introduction

Some User Stories are too big to be selected for the implementation. In that case, you must break them into smaller, more manageable pieces to deliver value faster and, ideally, start learning from customers using your product for real.