home / skills / dasien / claudemultiagenttemplate / user-story-writing

This skill helps write clear user stories in As a/I want/So that format with acceptance criteria and business value for team alignment.

npx playbooks add skill dasien/claudemultiagenttemplate --skill user-story-writing

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.7 KB
---
name: "User Story Writing"
description: "Create well-structured user stories with clear acceptance criteria in 'As a/I want/So that' format for team communication"
category: "analysis"
required_tools: ["Read", "Write"]
---

# User Story Writing

## Purpose
Create well-structured user stories that clearly communicate user needs, business value, and acceptance criteria in a format teams can understand and implement.

## When to Use
- Defining new features from user perspective
- Breaking down large features into implementable pieces
- Communicating requirements to development teams
- Planning sprints and iterations

## Key Capabilities
1. **Story Structure** - Write clear "As a/I want/So that" format
2. **Acceptance Criteria** - Define testable validation requirements
3. **Value Focus** - Emphasize user benefits and business value

## Approach
1. Identify the user role or persona
2. Define what they want to accomplish
3. Explain why it provides value
4. Write 3-5 clear acceptance criteria
5. Estimate complexity (story points or T-shirt sizes)

## Example
**Context**: User needs to export data
````markdown
**User Story**: As a data analyst, I want to export reports to CSV format, so that I can analyze data in Excel.

**Acceptance Criteria**:
- [ ] Export button available on report page
- [ ] CSV file includes all visible columns
- [ ] File download starts immediately on click
- [ ] Filename includes report name and timestamp
- [ ] Export handles reports with 10,000+ rows

**Complexity**: Medium (3 points)
````

## Best Practices
- ✅ Keep stories small and focused (deliverable in 1-3 days)
- ✅ Write from user perspective, not system perspective
- ✅ Make acceptance criteria specific and testable
- ❌ Avoid: Technical implementation details in stories

Overview

This skill creates well-structured user stories in the 'As a / I want / So that' format with clear, testable acceptance criteria and a simple complexity estimate. It helps teams communicate requirements, focus on user value, and break features into implementable pieces. The output is ready for sprint planning and handoff to development or QA.

How this skill works

I identify the user role or persona, define the goal they want to achieve, and state the business or user value. I then produce 3–5 specific acceptance criteria that are measurable and list a lightweight complexity estimate (story points or T-shirt size). The result is a concise story ready for backlog grooming and sprint inclusion.

When to use it

  • Defining a new feature from the user perspective
  • Breaking a large feature into smaller, implementable stories
  • Preparing items for sprint planning or backlog refinement
  • Communicating requirements clearly to developers and QA
  • Creating acceptance tests and definition of done

Best practices

  • Keep each story small and focused — ideally completable in 1–3 days
  • Write from the user perspective; avoid system-internal language
  • Make acceptance criteria specific, measurable, and testable
  • Avoid implementation details; capture intent and constraints instead
  • Include a simple complexity estimate to help prioritization

Example use cases

  • Turn a product idea into a prioritized, testable backlog item
  • Split a monolithic feature into multiple, deliverable stories
  • Create acceptance criteria for QA to validate feature completeness
  • Prepare developer-ready tasks for a sprint planning session
  • Document user-facing behavior for cross-functional alignment

FAQ

How many acceptance criteria should a story have?

Aim for 3–5 clear, testable criteria that cover core behavior, edge cases, and non-functional constraints relevant to the story.

Should I include implementation details in the story?

No. Focus on user intent and acceptance criteria. Save technical approach for tasks or design docs to avoid constraining the implementation.