Split a Large User Story Using SPIDR
Splits an oversized user story into smaller stories using the SPIDR method (Spike, Path, Interface, Data, Rules). Designed for PMs trying to fit work into a single sprint.
When to use this prompt
Use this when a user story is estimated at 13+ points and cannot fit in one sprint, or when a single story has grown to cover too many flows. The SPIDR method gives you 5 specific splitting techniques instead of guessing. You will need the original story and a rough understanding of the underlying complexity. This is most useful on stories where INVEST-style decomposition has failed because the story feels genuinely atomic. SPIDR often reveals that what felt atomic actually contains 3-4 independent decisions bundled together.
The Prompt
You are a product manager splitting a large user story into smaller ones using the SPIDR method (Spike, Path, Interface, Data, Rules). The goal is 3-6 smaller stories that each fit within one sprint. Original story: {{original_story}} Current estimate: {{current_estimate}} Target size per story: {{target_size}} For each SPIDR dimension, consider whether it applies and how: - SPIKE: Does the story contain research or unknown risk that could be isolated into a timeboxed spike? - PATH: Are there multiple user journeys (happy path vs. edge paths) that can be split into separate stories? - INTERFACE: Are there multiple platforms (web, mobile, API) that can be split? - DATA: Are there multiple data types or segments (small accounts vs. enterprise, English vs. localized) that can be split? - RULES: Are there multiple business rules that can be split into incremental rule delivery? For the dimensions that apply, produce split stories. For each split story: - Title - User story (As a... I want... so that...) - Estimated size - Which SPIDR dimension it uses - Why it is still independently valuable After the splits, produce: 1. RECOMMENDED SPLIT â Pick the best 3-6 stories that together cover the original scope. Order them by delivery sequence. 2. DROPPED DIMENSIONS â SPIDR dimensions that did not apply, with a 1-sentence reason. 3. THINNEST VALUABLE SLICE â Which of the split stories delivers the first real user value. This is what should ship first.
Example Output
Original: As a user, I want to export all my data across web, mobile, and API in 6 supported formats. Estimate: 21 points. SPIDR ANALYSIS SPIKE: Isolate format conversion research into a 2-day spike on streaming PDF generation. PATH: Split happy-path export from scheduled/recurring export. INTERFACE: Split web export from mobile export from API export. DATA: Split user data (small) from account data (large datasets requiring streaming). RULES: Split CSV (simplest rules) from JSON/PDF/Excel. RECOMMENDED SPLIT 1. Spike: Streaming PDF performance (2 pts, 3 days). Spike dimension. 2. As a web user, I want to export my personal data as CSV. (3 pts). Interface + Rules. 3. As a web user, I want to export my personal data as JSON and Excel. (3 pts). Rules. 4. As a web user, I want to export my account data (large) as streaming CSV. (5 pts). Data. 5. As a mobile user, I want to trigger a web export from my phone. (2 pts). Interface. 6. As an API consumer, I want a data export endpoint. (3 pts). Interface. DROPPED DIMENSIONS: Path did not apply because there is only one export journey. THINNEST VALUABLE SLICE: Story 2 (web CSV export for personal data) delivers real user value on its own.
Recommended Tools
Jira and Linear both support parent-child story relationships so the original story can become the parent and SPIDR splits become its children. Productboard is useful when the original story came from a discovery process, because the split can preserve the link back to the originating customer opportunity. All three tools let you reorder splits based on the thinnest valuable slice recommendation.
Frequently Asked Questions
When should I use this prompt?
Use it whenever a story has been estimated at 13 points or more and feels too big to fit in a sprint. SPIDR is best applied after simpler splitting (horizontal slices by flow) has been tried and failed. Do not use it on small stories; splitting them further just creates coordination overhead. Also avoid splitting stories that are already INVEST-compliant just because you like the SPIDR framework; splitting creates integration risk and should only be done when necessary.
What if multiple SPIDR dimensions apply?
That is common and fine. The recommended split in the output will usually combine 2-3 dimensions (e.g., splitting by interface and by rules at the same time). The key discipline is to make each resulting story independently valuable. If a split story cannot ship on its own without its siblings, reconsider the split; SPIDR is not about arbitrary chunking, it is about finding natural seams in the work where value can be delivered incrementally.