prd-to-stories

name	prd-to-stories
description	Break down a PRD into individual SMART Jira stories with acceptance criteria, story points, dependencies, and sprint-ready detail. Creates epic structure and story hierarchy from product requirements.
argument-hint	[prd-content-or-confluence-url]

PRD to Jira Stories

Break down a Product Requirements Document into well-structured, sprint-ready Jira stories organized under epics with clear acceptance criteria, dependencies, and estimates.

When to Use

• PRD is approved and ready for engineering breakdown
• Need to create a backlog of stories from requirements
• Converting a feature spec into actionable development work
• Preparing stories for sprint planning

Workflow

Step 1: Ingest the PRD

Accept PRD from one of:

• Pasted text in the conversation
• Confluence page (pull via Atlassian MCP if available)
• File path to a local document

Step 2: Analyze and Decompose

Read the entire PRD and identify:

• Functional requirements - what the system must do
• Non-functional requirements - performance, security, compliance
• User roles involved and their specific workflows
• Data model changes required
• Integration points with other systems
• Regulatory requirements (audit trails, e-signatures, validation)

Step 3: Create Epic Structure

Group requirements into epics:

Epic: [Feature Name] - [Component/Module]
  Description: High-level summary of this epic's scope
  Labels: feature-name, component
  Fix Version: [Target release]

Step 4: Generate Individual Stories

For EACH story, produce:

## Story: [EPIC-PREFIX]-[Number]
**Title:** As a [role], I want to [action] so that [benefit]

**Type:** Story | Task | Bug | Spike
**Story Points:** [1, 2, 3, 5, 8, 13]
**Priority:** Critical | High | Medium | Low
**Labels:** [feature], [component], [regulatory] if applicable
**Sprint Candidate:** Yes/No (is it self-contained enough for one sprint?)

### Description
[2-3 sentences describing what needs to be built and why.
Include relevant context from the PRD.]

### Acceptance Criteria
Given [precondition]
When [action]
Then [expected result]

- [ ] AC1: [Specific, testable criterion]
- [ ] AC2: [Specific, testable criterion]
- [ ] AC3: [Specific, testable criterion]
- [ ] AC4: [Regulatory criterion if applicable]

### Technical Notes
- Database changes: [if any]
- API changes: [if any]
- UI components: [if any]
- Migration considerations: [if any]

### Dependencies
- Blocked by: [story IDs]
- Blocks: [story IDs]

### Definition of Done
- [ ] Code complete and passes code review
- [ ] Unit tests written (>80% coverage for new code)
- [ ] Integration tests passing
- [ ] Acceptance criteria verified
- [ ] Documentation updated
- [ ] No critical/high security findings
- [ ] Audit trail requirements met (if clinical data)

Story Sizing Guidelines

Points	Complexity	Example
1	Trivial	Config change, copy update, add a field label
2	Simple	Add a form field with validation, new API parameter
3	Moderate	New form section, new API endpoint, simple query
5	Complex	New page/view, multi-step workflow, data migration
8	Very complex	New module, cross-system integration, complex business logic
13	Epic-level	Should be broken down further

Story Quality Checklist

Every story MUST be SMART:

• Specific: Clear what needs to be built
• Measurable: Acceptance criteria are testable
• Achievable: Can be completed in one sprint
• Relevant: Traces back to a PRD requirement
• Time-bound: Story pointed and sprint-assignable

Regulatory Story Patterns

For clinical trial EDC features, ensure these story types are included:

Audit Trail Stories:

• Capture who changed what, when, and why
• Store previous values for all clinical data changes
• Reason for change required on edits to completed forms

E-Signature Stories:

• Re-authentication required (username + password)
• Signature meaning displayed before signing
• Signed records locked from further editing without re-signature

Access Control Stories:

• Role-based permissions for each new feature
• Study-level and site-level access restrictions
• Privilege escalation prevention

Validation Stories:

• Field-level validation (data types, ranges, formats)
• Cross-field validation (edit checks)
• Form-level validation before completion

Step 5: Generate Summary

After all stories, provide:

## Breakdown Summary

| Epic | Story Count | Total Points | Dependencies |
|------|------------|--------------|--------------|
| ...  | ...        | ...          | ...          |

**Total Stories:** [count]
**Total Story Points:** [sum]
**Estimated Sprints:** [points / team velocity]
**Critical Path:** [list stories that block others]
**Recommended Sprint 1:** [stories with no dependencies, foundational work]

Step 6: Offer Next Actions

• "Want me to create these stories in Jira? (I'll use the Atlassian MCP)"
• "Shall I generate test cases for these stories? (use /requirements-test-matrix)"
• "Need acceptance criteria refined? (use /acceptance-criteria)"
• "Ready to plan the sprint? (use /sprint-planning)"