Split large stories without losing a useful outcome
Three before-and-after cases to narrow complete deliveries, maintain quality and estimate again meaningfully.
1. Discover what makes the story large
A high card may expose many scenarios, unresolved dependencies or an unclear outcome. No point threshold requires every team to split. Ask which part you cannot explain or verify yet.
This guide uses a fictional reporting and ordering product. Its decisions illustrate possibilities, not observed StoryFlop customer results. Before splitting, write who needs the outcome and what the first delivery enables.
2. Keep a complete journey
Separating “build the API”, “make the screen” and “test” may organise tasks without producing three useful stories. Look for a narrow capability including the layers and checks needed to work.
Narrowing scope does not mean removing permissions, accessibility or tests to lower a number. If exporting data requires checking who may see it, include that protection in the first delivery. Constraints must be explicit and acceptable to its users.
3. Choose a constraint you can explain
Start with one format, channel, user type or business rule. Manual CSV and scheduled PDF exports address different needs. Confirm which enables value or learning first; do not split merely because screens look separate.
If data volume or provider behaviour is unknown, define an investigation with a question, owner and review. Its findings may change the split. Do not promise a limited delivery nobody can actually use.
4. Check the split before voting
For each part, describe a demonstration: who enters, what they do and what outcome they verify. Include an error case and access conditions. If showing anything requires three other unfinished stories, reconsider the split.
Re-estimate each story with the same team and references. Do not mechanically distribute original points: splitting can uncover shared work, remove assumptions or change the solution. The parts need not add up to the original estimate.
5. Keep the link to the original need
Record first-delivery scope, deferred work and reasons. Link back to the original need and state dependencies between parts. Revisit whether the constraint remains useful when priorities change.
Next session, ask whether the first part can be verified and supported a decision. If it only created unfinished work, adjust the pattern. Keep these assumptions beside estimates in the refinement template.
Worked cases: from initial scope to a decision
Export reports
Before
“Export every report as CSV and PDF, with scheduling and all filters.” Volume and who can download each row are unclear.
After
First story: manually download one report as CSV, with agreed columns, existing permissions, an explicit volume limit and testable errors. PDF and scheduling are later outcomes.
Why this decision: Choose one format and a complete journey while keeping access checks and tests. Validate that the volume limit still makes the delivery useful.
Notification preferences
Before
“Configure every notification through email, mobile and in-app channels.” Different channels and rules are mixed.
After
First story: disable the weekly email summary, persist the preference and verify that sending respects it. Essential access-recovery messages remain active.
Why this decision: The preference works end to end. Do not deliver a visual switch separately from sending. Prioritise other channels after confirming this need.
View orders by role
Before
“A dashboard for every role and organisation, with search, export and administration.” Permissions and flows remain undefined.
After
First story: a person views their orders under existing authorisation, with reference search and empty/error states. Cross-organisation administration and export are excluded.
Why this decision: Narrow the persona and journey without postponing authorisation. If the existing policy does not cover access, resolve that question before calling the story ready.
Put it into practice
Sources and further reading
The examples and StoryFlop instructions were written for this section. These sources provide context for the method and refinement: