📝 User Story Writing

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.

This prompt applies the SPIDR method to split a large user story into 3-6 smaller stories, each fitting within a single sprint. SPIDR stands for Spike, Path, Interface, Data, and Rules, and each dimension represents a distinct splitting strategy.

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

Role: Product Manager Variables: {{original_story}}, {{current_estimate}}, {{target_size}}
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.

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.