User Stories

What Is This?

Overview

User Stories is a structured skill for creating well-formed agile user stories that follow two foundational frameworks: the 3 C's (Card, Conversation, Confirmation) and the INVEST criteria. The skill guides product managers, designers, and developers through the process of translating feature ideas into actionable backlog items that are clear, testable, and appropriately scoped. Each generated story includes a concise description, relevant design links, and explicit acceptance criteria.

The 3 C's framework treats a user story as more than a written statement. The Card captures the brief narrative, the Conversation represents the ongoing dialogue between stakeholders, and the Confirmation defines the conditions that prove the story is complete. The INVEST criteria, which stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable, provides a quality checklist to ensure every story is ready for development without ambiguity or excessive dependency.

This skill is particularly useful when breaking down large features into discrete backlog items, when preparing stories for sprint planning, or when establishing shared understanding between product and engineering teams. It produces consistent, professional output that reduces back-and-forth during refinement sessions.

Who Should Use This

• Product managers who need to write and maintain a well-groomed product backlog
• UX designers who want to connect design artifacts directly to development requirements
• Scrum masters and agile coaches who facilitate backlog refinement and sprint planning
• Software engineers who need clear acceptance criteria before beginning implementation
• Business analysts translating stakeholder requirements into development-ready stories
• Startup founders or solo builders who manage their own product roadmap without a dedicated PM

Why Use It?

Problems It Solves

• Vague or incomplete requirements that lead to misaligned implementations and rework
• Inconsistent story formats across team members that slow down refinement sessions
• Missing acceptance criteria that make it impossible to determine when a story is truly done
• Oversized stories that cannot be completed within a single sprint, causing carry-over and planning failures
• Disconnected design artifacts that are referenced informally rather than embedded in the story itself

Core Highlights

• Enforces the 3 C's structure to ensure stories are collaborative and confirmable
• Applies INVEST criteria as a built-in quality gate for every generated story
• Includes a dedicated field for design links, keeping Figma or other design files traceable
• Generates explicit acceptance criteria in a consistent, testable format
• Supports breaking down epics and large features into smaller, sprint-ready items
• Produces output that integrates directly into tools like Jira, Linear, or Notion
• Reduces time spent in refinement by delivering stories that are already well-structured

How to Use It?

Basic Usage

A standard user story follows this format:

As a [user type],
I want to [perform an action],
So that [I achieve a goal].

Description:
[Additional context about the feature, edge cases, or constraints]

Design Links:
- Figma: https://figma.com/file/...

Acceptance Criteria:
- Given [context], when [action], then [outcome]
- Given [context], when [action], then [outcome]

Specific Scenarios

Scenario 1: Breaking down a feature into backlog items When a feature like "user authentication" is too large for a single sprint, use this skill to split it into stories such as email registration, password reset, and social login, each with its own acceptance criteria and design reference.

Scenario 2: Preparing stories for sprint planning Before a planning session, run each candidate story through the INVEST checklist. If a story is not estimable or is too large, the skill helps rewrite or split it into a form the team can commit to confidently.

Real-World Examples

• An e-commerce team writes a story for a guest checkout flow, linking the Figma prototype and defining three acceptance criteria covering happy path, validation errors, and order confirmation.
• A SaaS product manager breaks an "admin dashboard" epic into six independent stories, each covering a distinct widget or data view, making sprint allocation straightforward.

Important Notes

Requirements

• A clear understanding of the target user type or persona before writing the story
• Access to design artifacts or wireframes when the story involves UI changes
• Stakeholder alignment on the business goal the story is meant to address
• Familiarity with the team's sprint capacity to size stories appropriately