사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/product-on-purpose/pm-skills --skill deliver-user-stories시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
User Stories
User stories are concise descriptions of functionality from the user's perspective. They capture who needs something, what they need, and why - without prescribing how to build it. Good user stories enable teams to break large features into estimable, deliverable increments while maintaining focus on user value.
When to Use
- After PRD approval, when breaking down features for implementation
- During sprint planning to create actionable work items
- When writing tickets for engineering teams
- When communicating requirements to stakeholders in accessible terms
- When prioritizing a backlog based on user value
When NOT to Use
- You need deeper, QA-ready Given/When/Then coverage for a single story or slice -> use
deliver-acceptance-criteria - You need the feature-wide catalog of boundary conditions and failure scenarios -> use
deliver-edge-cases - The feature itself is not yet specified -> use
deliver-prdfirst; stories should trace back to documented requirements - You want refinement-session outcomes (estimates, scope decisions, open questions) -> use
iterate-refinement-notes
Instructions
When asked to create user stories, follow these steps:
- Understand the Feature Context
Review the PRD or feature description. Understand the overall goal, target users, and scope boundaries. User stories should trace back to documented requirements.
- Identify User Personas
Determine which users interact with this feature. Each story should be written for a specific persona, not generic "users." Different personas may need different stories for the same feature.
- Break Down by User Goal
Decompose the feature into distinct user goals. Each story should deliver a complete, valuable capability - something the user can actually do when the story is done.
- Write Story Statements
Use the format: "As a [persona], I want [action] so that [benefit]." The benefit clause is critical - it explains why this matters and helps prioritize.
- Define Acceptance Criteria
Write specific, testable criteria using Given/When/Then format. Acceptance criteria define "done" - if all criteria pass, the story is complete.
- Apply INVEST Criteria
Validate each story against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Revise stories that don't meet these criteria.
- Add Context and Notes
Include relevant design references, technical considerations, and dependencies. These help implementers understand the full picture.
Output Format
Use the template in references/TEMPLATE.md to structure the output. A complete output carries, per story: Story Header; User Story Statement; Context & Background; Acceptance Criteria; Design Notes; Technical Notes; Dependencies; Out of Scope; and Open Questions where any remain. Multi-story documents nest these sections under one heading per story, as the example shows.
Quality Checklist
Before finalizing, verify:
- [ ] Each story follows "As a... I want... so that..." format
- [ ] Stories are independent (can be built in any order)
- [ ] Acceptance criteria use Given/When/Then format
- [ ] Each criterion is testable (someone can verify pass/fail)
- [ ] Stories are small enough to complete in one sprint
- [ ] No implementation details in the story statement
- [ ] Benefit clause explains why this matters to the user
Examples
See references/EXAMPLE.md for a completed example.
