mirror of
https://github.com/phuryn/pm-skills.git
synced 2026-06-12 22:44:55 +03:00
Pawel Huryn
113 lines
3.8 KiB
Markdown
113 lines
3.8 KiB
Markdown
---
|
|
description: Break a feature into backlog items — user stories, job stories, or WWA format with acceptance criteria
|
|
argument-hint: "[user|job|wwa] <feature description or PRD>"
|
|
---
|
|
|
|
# /write-stories -- Backlog Item Generator
|
|
|
|
Break a feature into well-structured backlog items. Choose from three formats based on your team's preference, each with full acceptance criteria.
|
|
|
|
## Invocation
|
|
|
|
```
|
|
/write-stories user Allow users to export reports as PDF and CSV
|
|
/write-stories job Notification system for task deadlines
|
|
/write-stories wwa Dark mode for the mobile app
|
|
/write-stories [upload a PRD or feature spec] # asks format preference
|
|
/write-stories # asks for feature and format
|
|
```
|
|
|
|
## Formats
|
|
|
|
### User Stories
|
|
**Format**: "As a [user type], I want [capability], so that [benefit]"
|
|
Apply the **user-stories** skill:
|
|
- Follow the 3 C's: Card (brief), Conversation (context), Confirmation (acceptance criteria)
|
|
- Validate against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
|
|
- Include design links or mockup references where relevant
|
|
|
|
### Job Stories
|
|
**Format**: "When [situation], I want to [motivation], so I can [outcome]"
|
|
Apply the **job-stories** skill:
|
|
- Focus on the situation and context, not the user role
|
|
- Ground in real user scenarios observed in research
|
|
- Ideal for JTBD-oriented teams
|
|
|
|
### WWA (Why-What-Acceptance)
|
|
**Format**: Why [strategic context] → What [deliverable] → Acceptance [criteria]
|
|
Apply the **wwas** skill:
|
|
- Includes strategic reasoning (why we're building this)
|
|
- Produces independent, valuable, testable items
|
|
- Good for cross-functional teams that need business context
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Accept the Feature
|
|
|
|
Accept in any form: PRD, feature description, user research finding, or verbal idea. If a PRD is provided, extract the requirements to decompose.
|
|
|
|
### Step 2: Determine Format
|
|
|
|
If not specified in the invocation, ask:
|
|
- "Which format does your team use? **User stories**, **Job stories**, or **WWA**?"
|
|
- If unsure, recommend user stories as the default
|
|
|
|
### Step 3: Decompose the Feature
|
|
|
|
- Break the feature into 5-15 independent stories (small enough to complete in one sprint)
|
|
- Ensure each story is independently valuable (delivers user value on its own)
|
|
- Order by dependency and priority
|
|
- Write 3-5 acceptance criteria per story
|
|
- Flag stories that need design input or technical spikes
|
|
|
|
### Step 4: Generate Stories
|
|
|
|
```
|
|
## Backlog: [Feature Name]
|
|
|
|
**Format**: [User Stories / Job Stories / WWA]
|
|
**Total stories**: [count]
|
|
**Estimated total effort**: [if possible]
|
|
|
|
### Stories
|
|
|
|
#### Story 1: [Short title]
|
|
**[The story in chosen format]**
|
|
|
|
Acceptance Criteria:
|
|
- [ ] [Criterion 1]
|
|
- [ ] [Criterion 2]
|
|
- [ ] [Criterion 3]
|
|
|
|
Priority: [P0/P1/P2] | Effort: [S/M/L] | Dependencies: [none or list]
|
|
|
|
---
|
|
[Repeat for each story]
|
|
|
|
### Story Map
|
|
[Visual ordering: must-have → should-have → nice-to-have]
|
|
|
|
### Technical Notes
|
|
[Cross-cutting concerns: API changes, data migration, infrastructure]
|
|
|
|
### Open Questions
|
|
[Things that need answers before implementation can start]
|
|
```
|
|
|
|
Save as markdown.
|
|
|
|
### Step 5: Offer Next Steps
|
|
|
|
- "Want me to **generate test scenarios** for these stories?"
|
|
- "Should I **create dummy data** for development and testing?"
|
|
- "Want me to **estimate sprint capacity** for these stories?"
|
|
- "Should I **convert to a different format** (user stories ↔ job stories ↔ WWA)?"
|
|
|
|
## Notes
|
|
|
|
- One story = one deployable unit of value — if it needs another story to be useful, they should be combined
|
|
- Acceptance criteria should be testable by QA without additional interpretation
|
|
- Error handling and edge cases deserve their own stories, not bullet points within a happy-path story
|
|
- If the feature is large (15+ stories), suggest grouping into epics or phases
|
|
- Flag any story that requires a spike (technical investigation before estimation is possible)
|