User Stories are narratives that foster collaboration, guide development and drive meaningful outcomes.
But many use them as containers for requirements.
So here's User Stories 101:
-
1. Why?
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.
-
2. How?
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]
A prerequisite to working with User Stories is understanding the users, ideally segmented by their needs and desired outcomes.\
-
3. Effective User Stories: 3C's
The 3 C's of User Stories are essential for writing a good User Story:
Card: A card explaining WHO, WHAT, and WHY. They once were physical cards, but today, we create User Stories in tools like Jira.
Conversation:Rather than creating a detailed specification, discuss the reasoning behind the User Story. Everyone needs to understand not just how the User Story will benefit the users but also how it will contribute to the Product Outcome and how it aligns with your product strategy.
Confirmation: Confirmation refers to the Acceptance Criteria that should be fulfilled to ensure the requirements have been met and delivered correctly. It's a concise checklist, not detailed test cases.
-
4. 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.
Those qualities are desirable. But do not obsess over the acronym.
-
5. How to Split User Stories?
Some User Stories are too big to be selected for the implementation. You must break them into smaller, more manageable pieces to deliver value faster and, ideally, start learning from customers using your product for real.
Epic: A larger element, typically combining 5-15 smaller User Stories (that's context-specific).
User Stories: Small, manageable items.
Tasks: Used to plan and monitor the exact work performed by Engineers. PMs have nothing to say here.
Some add more layers, but in my experience, you don't need that.
Keep it simple.
—
Do you agree? Disagree?
—
P.S. Enjoy this?
See the full post, How to Write User Stories: The Ultimate Guide: productcompass.pm/p/how…
Download 30+ free high-quality infographics by subscribing here: bit.ly/pmposters
