How to Write User Stories Using the 3 C's and INVEST Criteria: A Complete Guide

The best practice for writing user stories follows the 3 C's framework (Card, Conversation, Confirmation) and validates each story against the six INVEST attributes (Independent, Negotiable, Valuable, Estimable, Small, Testable).

The phuryn/pm-skills repository codifies these industry standards in a dedicated user stories skill that helps product teams create clear, actionable backlog items. According to the source specification in pm-execution/skills/user-stories/SKILL.md, well-written stories act as placeholders for conversation while providing concrete acceptance criteria for implementation.

Understanding the 3 C's Framework

The 3 C's provide a structured approach to capturing requirements without over-specifying solutions upfront.

Card

The Card represents the initial, concise description of the user story. It serves as a physical or digital placeholder in your backlog that captures the essence of the requirement in a single line.

Keep card titles short and actionable, such as "Export reports as PDF" or "Reset password via email." This brevity allows for quick backlog triage and prioritization while leaving room for the details that follow.

Conversation

The Conversation expands the card into a discussion about the user intent, context, and implementation details. This is where the team collaborates to understand the why behind the request.

Document the conversation using the standard format: "As a [user role], I want [action], so that [benefit]." For example: "As a Finance Analyst, I want to export reports as PDF so that I can share them with auditors." The pm-skills repository emphasizes that this text should be understandable by "a primary-school graduate" to ensure clarity across technical and non-technical stakeholders.

Confirmation

The Confirmation phase produces explicit, testable acceptance criteria that define when the story is complete. These criteria transform the conversation into verifiable specifications.

Write 3–6 measurable statements that QA can execute against. For instance, "The export completes within 5 seconds for reports up to 100 pages" provides a concrete testable threshold. The skill file at pm-execution/skills/user-stories/SKILL.md specifies that confirmation criteria must be concrete enough to verify the Testable attribute of INVEST.

Applying the INVEST Criteria

Every user story must satisfy the six INVEST attributes to ensure it is ready for sprint planning. Validate your story against each criterion before committing it to an iteration.

Independent

Stories should be self-contained and capable of being delivered without dependencies on other incomplete stories. If Story A cannot be released until Story B finishes, consider merging them or restructuring the scope.

Negotiable

A story is not a contract—it is a placeholder for dialogue. The wording should remain flexible, allowing the team to negotiate implementation details, scope, and approach during the sprint.

Valuable

Each story must deliver clear user value to an end-user or stakeholder, not just technical infrastructure. If a story only benefits the development team (e.g., "Refactor database"), reframe it in terms of user outcomes (e.g., "Reduce report generation time").

Estimable

The team must possess enough detail to size the work during sprint planning. If a story is too vague to estimate, break it down or add more context through the Conversation phase.

Small

Stories should be small enough to fit within a single sprint or iteration. Large, vague requirements (epics) must be decomposed into smaller stories that can be completed in a few days.

Testable

Include clear acceptance criteria that allow QA to verify completion objectively. Vague requirements like "should be fast" fail this criterion; specific metrics like "loads in under 2 seconds" pass.

Writing User Stories in Practice

The pm-skills repository provides a standardized template and automation command to ensure consistency. When writing user stories using the 3 C's and INVEST criteria, follow this structure:

**Title:** Export Reports as PDF

**Description:** As a **Finance Analyst**, I want to **export reports as PDF** so that I can **share them with auditors**.

**Design:** https://www.figma.com/file/xyz/export-reports

**Acceptance Criteria:**
1. The "Export as PDF" button appears on the reports toolbar for all users with the *Analyst* role.
2. Clicking the button triggers a PDF download that matches the on-screen layout exactly.
3. PDF files are named `Report_<YYYYMMDD>_<ReportID>.pdf`.
4. The export completes within 5 seconds for reports up to 100 pages.
5. Errors (e.g., network failure) display a user-friendly message and allow retry.
6. The feature is covered by automated UI tests that verify criteria 1-5.

To generate stories automatically according to these specifications, use the repository's command:

/write-stories user Export reports as PDF and CSV

As documented in pm-execution/commands/write-stories.md, this command outputs stories in the exact format above, linking design files and populating acceptance criteria per the skill definition. The command ensures each generated story follows the 3 C's + INVEST pattern, particularly enforcing the Small and Testable attributes through structured decomposition.

Summary

• Card provides a concise title for backlog triage, while Conversation captures user intent and Confirmation delivers testable acceptance criteria.
• Validate every story against INVEST: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
• Reference the pm-execution/skills/user-stories/SKILL.md file for the complete specification and pm-execution/commands/write-stories.md for automation options.
• Write descriptions in plain language that a primary-school graduate can understand, and always link to design artifacts when applicable.

Frequently Asked Questions

What is the difference between the Card and the Description in a user story?

The Card is the single-line title (e.g., "Export reports as PDF") that acts as a quick reference for backlog management. The Description expands into the full user narrative using the "As a... I want... so that..." format. According to the pm-skills repository, the Card captures the gist while the Description contains the Conversation details that explain user intent and context.

How do I know if my user story is small enough?

A story is Small enough when it can be completed by the team within a single sprint, typically requiring only a few days of work. If the story involves multiple user roles, spans multiple systems, or requires more than a week to implement, decompose it further. The write-stories command in pm-execution/commands/write-stories.md automatically guides this decomposition process to ensure sprint-sized chunks.

Can I write user stories for technical tasks like refactoring?

While the INVEST criteria emphasize Valuable outcomes for end-users, technical work can be framed as user stories if it delivers visible benefits. Instead of "Refactor the database," write "Reduce report generation time by 50% to improve analyst productivity." If the work truly has no user-facing value, consider treating it as a task or sub-task rather than a standalone user story.

Where should I store design links and visual references?

Include design URLs in the Conversation section of your story, typically under a dedicated "Design" field. The pm-skills specification recommends linking to Figma, Miro, or similar artifacts at pm-execution/skills/user-stories/SKILL.md#L21-L28 to ensure implementation aligns with UI/UX specifications while maintaining the story's role as a negotiable placeholder.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}