story-splitting

Reframe the parent as actor, capability, and outcome, then surface examples and split along dimensions like path, interface, data, rules, or quality. Each child story must deliver an end-to-end user-visible capability, not a technical layer.

A vertical slice changes behavior visible to a real user or external system and runs through the real production path. Component tasks like "build the API" or "add the database table" are work items inside a story, not independently valuable stories.

SPIDR splits stories by Spike, Path, Interface, Data, and Rules. Use it as a quick checklist: isolate a happy path, one channel, a data subset, or a scoped business rule, and reserve spikes for specific unanswered questions.

Use it when the team keeps decomposing work into technical layers. List the layers, list simpler-to-richer options per layer, then take a first bite across every layer so the result stays end-to-end.

Yes, if the release constraint is stated explicitly, such as internal-only, demo-only, or disposable tracer. Safety, legal, privacy, and security requirements must never be deferred without a clear non-release constraint.

Do not use it to resolve open product decision trees, to produce implementation tasks, or to inspect an existing plan for gaps. Use decision-making skills first, then split, then hand the selected child story to implementation planning.