User Stories: Splitting, Estimation & Team Practices

Splitting Large (Epic-Sized) Stories

TOO LARGE: As a user, I want a complete checkout experience.

SPLIT INTO:
- As a user, I want to add items to a cart.
- As a user, I want to enter shipping info.
- As a user, I want to pay via credit card.

Smaller stories are easier to estimate, fit within a sprint, and
surface blocking problems early -- rather than discovering a serious
issue on day 9 of a two-week unbroken story.

Personas: Making Stories Concrete

Generic: As a user, I want to reorder items.

With a persona: As Sarah, a busy working parent, I want to quickly
reorder my last grocery list, so that I save time on weekly shopping.

Story Points vs. Hours

Story points measure RELATIVE effort/complexity (often on a Fibonacci-like scale: 1, 2, 3, 5, 8) rather than a literal time estimate. Humans tend to be better at judging 'this is roughly twice as complex as that' than accurately predicting exact hours.

Spikes: Investigating Before Estimating

A spike is a time-boxed research task answering a specific technical question before a related story can be accurately estimated -- e.g. 'investigate whether library X handles our expected data volume.' Its output is a decision/knowledge, not a shippable feature.

Team Practices

• Backlog grooming -- ongoing review/refinement of upcoming stories before they enter a sprint, catching ambiguity or oversized stories early.

• Definition of Done -- team-wide quality standards (tests pass, code reviewed) applying to every story, distinct from a specific story's own acceptance criteria.

• Stories vs. tasks -- a story captures user-facing value; tasks are the specific engineering work items ('add migration', 'build endpoint') needed to implement it.

• A story is negotiable -- if implementation reveals the original understanding was incomplete, raise it and adjust rather than rigidly building the literal original wording.