User Story

What is a User Story?

A user story is the unit of work that engineering executes. It is intentionally small and focused: one story represents one day to one week of engineering effort. It is written from the user’s perspective to maintain focus on customer value rather than technical implementation.

The canonical form is: “As a [user type], I want to [action], so that [outcome].” For example: “As a designer, I want to export my board as PDF, so that I can share it in presentations.” This structure forces clarity on three dimensions: who is the user, what do they want, and why.

User Story vs. Epic vs. Initiative

User stories form a hierarchy. An initiative or epic is a large outcome (e.g., “enable collaboration in shared workspaces”). Epics decompose into user stories (e.g., “enable real-time cursors,” “enable comment threads,” “enable permission control”). User stories are executable units; epics are outcomes.

The value of this hierarchy is clarity and scope. An epic is too large to execute in a sprint. A task (“implement database migration”) is implementation detail. A user story sits in the middle—big enough to be meaningful, small enough to be executable.

Acceptance Criteria

Every user story includes acceptance criteria: testable statements that define when the story is complete. Acceptance criteria answer: what must be true for this story to be done?

Good acceptance criteria are specific and measurable: “when a user clicks the export button, a PDF download begins” is testable. “Make the export feature user-friendly” is not. Criteria should cover the happy path and critical edge cases.

User Stories in Backlogs

A well-groomed backlog is a backlog of well-defined user stories, prioritized by impact and sequenced for efficient execution. Grooming—the process of writing and refining stories—is PM work. It is not always glamorous, but it is foundational to execution efficiency.

Poorly groomed backlogs are storage for ideas, not roadmaps for execution. Engineers arrive to work without clear direction. PMs add stories during sprints rather than before. The backlog balloons with low-priority noise.

User Stories as Conversation

User stories are conversation starters, not conversation endings. The story prompts questions: How do users access this feature? What if the export fails? What formats do we support? These questions are answered through discussion between PM and engineering, not through exhaustive documentation upfront.

This conversation approach (called “As a user story”) distinguishes this practice from detailed technical specifications. The story provides structure; conversation fills in details.

Why It Matters for Product People

User stories discipline thinking. A PM who struggles to write a clear user story probably has not clarified the work themselves. The act of writing forces rigor.

User stories also enable autonomy. Engineers with clear stories can execute without constant PM interruption. This scales PM impact: one PM can unblock multiple teams through clear story-writing.

Related Concepts

User stories connect to requirements documentation (the higher-level specification), product ownership (validation of completion), and product operations (the systems that manage story creation and execution).