deliver-user-stories

Name: deliver-user-stories
Author: product-on-purpose

486stars64forks

How to install deliver-user-stories?

product-on-purpose/pm-skills/deliver-user-stories

$npx -y skills add product-on-purpose/pm-skills --skill deliver-user-stories

Installs into the current project.

Summary

Generates user stories in the standard persona, action, benefit story format from product requirements or feature descriptions. Use when breaking a feature into stories for sprint planning, writing tickets, or communicating scope to engineering. For testable Given/When/Then accep

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# User Stories
3
4	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.
5
6	## When to Use
7
8	- After PRD approval, when breaking down features for implementation
9	- During sprint planning to create actionable work items
10	- When writing tickets for engineering teams
11	- When communicating requirements to stakeholders in accessible terms
12	- When prioritizing a backlog based on user value
13
14	## When NOT to Use
15
16	- You need deeper, QA-ready Given/When/Then coverage for a single story or slice -> use `deliver-acceptance-criteria`
17	- You need the feature-wide catalog of boundary conditions and failure scenarios -> use `deliver-edge-cases`
18	- The feature itself is not yet specified -> use `deliver-prd` first; stories should trace back to documented requirements
19	- You want refinement-session outcomes (estimates, scope decisions, open questions) -> use `iterate-refinement-notes`
20
21	## Instructions
22
23	When asked to create user stories, follow these steps:
24
25	1. Understand the Feature Context
26	Review the PRD or feature description. Understand the overall goal, target users, and scope boundaries. User stories should trace back to documented requirements.
27
28	2. Identify User Personas
29	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.
30
31	3. Break Down by User Goal
32	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.
33
34	4. Write Story Statements
35	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.
36
37	5. Define Acceptance Criteria
38	Write specific, testable criteria using Given/When/Then format. Acceptance criteria define "done" - if all criteria pass, the story is complete.
39
40	6. Apply INVEST Criteria
41	Validate each story against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Revise stories that don't meet these criteria.
42
43	7. Add Context and Notes
44	Include relevant design references, technical considerations, and dependencies. These help implementers understand the full picture.
45
46	## Output Format
47
48	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.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] Each story follows "As a... I want... so that..." format
55	- [ ] Stories are independent (can be built in any order)
56	- [ ] Acceptance criteria use Given/When/Then format
57	- [ ] Each criterion is testable (someone can verify pass/fail)
58	- [ ] Stories are small enough to complete in one sprint
59	- [ ] No implementation details in the story statement
60	- [ ] Benefit clause explains why this matters to the user
61
62	## Examples
63
64	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type

deliver-user-stories

486stars64forks

View on GitHub

How to install deliver-user-stories?

product-on-purpose/pm-skills/deliver-user-stories

$npx -y skills add product-on-purpose/pm-skills --skill deliver-user-stories

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# User Stories
3
4	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.
5
6	## When to Use
7
8	- After PRD approval, when breaking down features for implementation
9	- During sprint planning to create actionable work items
10	- When writing tickets for engineering teams
11	- When communicating requirements to stakeholders in accessible terms
12	- When prioritizing a backlog based on user value
13
14	## When NOT to Use
15
16	- You need deeper, QA-ready Given/When/Then coverage for a single story or slice -> use `deliver-acceptance-criteria`
17	- You need the feature-wide catalog of boundary conditions and failure scenarios -> use `deliver-edge-cases`
18	- The feature itself is not yet specified -> use `deliver-prd` first; stories should trace back to documented requirements
19	- You want refinement-session outcomes (estimates, scope decisions, open questions) -> use `iterate-refinement-notes`
20
21	## Instructions
22
23	When asked to create user stories, follow these steps:
24
25	1. Understand the Feature Context
26	Review the PRD or feature description. Understand the overall goal, target users, and scope boundaries. User stories should trace back to documented requirements.
27
28	2. Identify User Personas
29	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.
30
31	3. Break Down by User Goal
32	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.
33
34	4. Write Story Statements
35	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.
36
37	5. Define Acceptance Criteria
38	Write specific, testable criteria using Given/When/Then format. Acceptance criteria define "done" - if all criteria pass, the story is complete.
39
40	6. Apply INVEST Criteria
41	Validate each story against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Revise stories that don't meet these criteria.
42
43	7. Add Context and Notes
44	Include relevant design references, technical considerations, and dependencies. These help implementers understand the full picture.
45
46	## Output Format
47
48	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.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] Each story follows "As a... I want... so that..." format
55	- [ ] Stories are independent (can be built in any order)
56	- [ ] Acceptance criteria use Given/When/Then format
57	- [ ] Each criterion is testable (someone can verify pass/fail)
58	- [ ] Stories are small enough to complete in one sprint
59	- [ ] No implementation details in the story statement
60	- [ ] Benefit clause explains why this matters to the user
61
62	## Examples
63
64	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type