delivery-planning

PRD to Stories

Transforms product requirement text into a structured backlog package with stories, acceptance criteria, risks, and delivery notes.

Open this workflow

Version 1.1.0

Inputs

- PRD or Feature Brief
- Delivery Constraints
- Target Release or Timeframe

Output schema

- Feature Summary
- User Personas
- Stories
- Acceptance Criteria
- Edge Cases
- Dependencies
- Risks

Downloadable assets

- Prompt pack (Markdown)
- Template definition (JSON)
- Story quality checklist

Overview

How this module works

PRD to Stories

Convert a feature brief or PRD into an implementation-ready backlog package.

Best for

After requirements workshops
Before sprint planning
When handing work to engineering or QA
When a feature brief is still too narrative for delivery planning

Source material

Product requirement text
Feature brief
Scope summary

What this workflow produces

Feature summary
User personas
Stories
Acceptance criteria
Edge cases
Dependencies
Risks

Why teams use it

It shortens the gap between product intent and engineering-ready backlog structure. Instead of manually rewriting a PRD into stories, acceptance criteria, and risk notes, the team gets a repeatable planning artifact.

Instructions

Usage guidance

Instructions

Recommended workflow

Paste the latest approved PRD or feature brief
Keep assumptions visible instead of removing ambiguity
Review stories for sprint-sized scope after generation
Add technical constraints manually if they are not in the source

What good output looks like

Stories are logically grouped and not overly broad
Acceptance criteria are testable, not narrative
Edge cases are separated from normal flow behavior
Dependencies and unresolved risks are visible before planning begins

Customization tips

Add your team story format
Add release labels or epic grouping rules
Append a QA handoff section if needed

Common mistakes

Adding scope that is not present in the source brief
Merging multiple features into one oversized story
Treating missing personas or dependencies as confirmed facts

Assets

Export and packaging notes

Downloadable Assets

Markdown prompt pack
JSON template definition
Story quality checklist

Recommended channel adaptations

Jira: add project keys, labels, or estimate fields to the story format
Notion: group the output into planning sections with assumptions and open questions
Email: summarize the feature intent and top risks before listing story details

Notes

Use the JSON export when embedding this workflow in internal generators or handoff tools.

Examples

Production examples built into this workflow.

Role-based approval flow

A strong product handoff example with personas, story slicing, testable acceptance criteria, and dependency visibility.

standardFlagship workflow example

Source input

Build a role-based approval flow for expense policy changes. Admins can propose a policy update, finance approvers review it, and once approved the new policy becomes active on its effective date. Need auditability, approval history, and notifications to impacted admins.

Structured output

feature summary

A role-based flow for proposing, approving, and activating expense policy updates with traceability.

user personas

Admin; Finance approver

stories

As an admin, I can submit a policy change proposal; As a finance approver, I can review and approve or reject a proposal; As an admin, I can view approval history for submitted policy changes

acceptance criteria

Approved policies activate on the configured effective date; Approval and rejection actions are recorded with timestamps; Impacted admins receive a notification when policy status changes

edge cases

Effective date is in the past; Approver changes while a proposal is pending

dependencies

Notification service; Audit log storage

risks

Unclear whether multiple approvers are needed for high-risk changes

Customer health dashboard filters

A realistic PM brief where reporting usefulness, default views, and maintenance risk all need to be captured in backlog form.

standardOperational scenario

Source input

Add saved views to the customer health dashboard so customer success managers can move quickly between renewal-risk reviews, onboarding-health reviews, and executive summaries. Users should save personal views, rename them, set one default, and recover gracefully if dashboard fields later change. The feature should reduce repeated filtering work during weekly account reviews.

Structured output

feature summary

Saved dashboard views reduce repeated filtering work and help customer success teams move quickly between recurring account-review contexts.

user personas

Customer success manager

stories

As a customer success manager, I can save a custom dashboard view for a repeat review workflow; As a customer success manager, I can rename or delete a saved view; As a customer success manager, I can mark one saved view as my default; As a customer success manager, I can recover when a saved view references fields that have changed

acceptance criteria

Users can save a view with a custom name; Only one default view may exist per user; The default view loads when the dashboard opens; Users receive a clear fallback state if a saved view references deprecated fields

edge cases

User deletes the current default view; Saved view references a field no longer available; Saved view includes filters the user can no longer access

dependencies

User preference storage; Dashboard filter state persistence; Field metadata service for compatibility checks

risks

Saved-view migration may be needed if dashboard field definitions change significantly

Vendor onboarding checklist

standard

Source input

Create a vendor onboarding checklist experience for procurement admins. The checklist should show required setup tasks, track completion, and allow admins to invite finance reviewers when vendor bank details need verification.

Structured output

feature summary

A checklist experience guides procurement admins through vendor onboarding and supports finance review when needed.

user personas

Procurement admin; Finance reviewer

stories

As a procurement admin, I can see required vendor onboarding tasks; As a procurement admin, I can mark tasks complete and resume later; As a procurement admin, I can invite a finance reviewer for bank detail verification

acceptance criteria

Checklist status persists across sessions; Verification tasks clearly indicate when finance review is required; Users can see which steps remain incomplete

edge cases

Reviewer invite fails; A verification step is skipped and later becomes mandatory

dependencies

Notification workflow; Vendor profile service

risks

Bank detail verification requirements may vary by region

Messy feature brief

messy

Source input

Need better reporting maybe for leaders and team leads. Something around weekly summary and maybe drill-down. Also alerts if things get stuck. Not sure if this belongs in current release.

Structured output

feature summary

The brief suggests a reporting enhancement with summary, drill-down, and alerting needs, but scope is not yet clear.

user personas

Leader (assumed); Team lead (assumed)

stories

As a leader, I can view a weekly summary of key delivery signals; As a team lead, I can inspect underlying drill-down details; As a stakeholder, I can receive alerts when work is stuck

acceptance criteria

Summary content is defined before implementation; Alert threshold logic is clarified; Release inclusion is confirmed

edge cases

Reporting data is delayed; Alerting is too noisy without threshold tuning

dependencies

Reporting data source; Alerting infrastructure

risks

Scope and release placement are unclear

Incomplete requirement note

incomplete

Source input

Users need a faster way to upload files in onboarding.

Structured output

feature summary

The requirement targets faster onboarding file upload, but the user journey and constraints are missing.

user personas

End user (assumed)

stories

As an onboarding user, I can upload files with fewer steps

acceptance criteria

Success measures for faster upload are defined before implementation

edge cases

Large files; Unsupported file type

dependencies

Existing upload service

risks

No details on target users, file types, or performance expectations

PRD output adapted for Notion handoff

Shows the same PRD workflow formatted for a collaborative planning document with clearer assumptions and handoff sections.

channelNotion adaptation

Source input

Introduce renewal-risk watchlists for customer success leads. Users should create watchlists, add accounts manually or through filters, and receive a weekly digest summarizing at-risk renewals and recent account changes.

Structured output

feature summary

Renewal-risk watchlists help customer success leads monitor at-risk accounts through saved groups and a weekly digest.

user personas

Customer success lead; Customer success manager

stories

As a customer success lead, I can create a renewal-risk watchlist; As a customer success manager, I can add accounts manually or via filters; As a watchlist owner, I can receive a weekly digest of at-risk accounts and notable changes

acceptance criteria

Users can create and name a watchlist; Accounts can be added manually and through saved filter logic; Weekly digest includes new risks and meaningful account changes

edge cases

Account ownership changes after it is added to a watchlist; Digest includes duplicate accounts from overlapping filters

dependencies

Digest email service; Customer health scoring data; Saved filter infrastructure

risks

The threshold for at-risk classification may need calibration before launch