How to Know When a Story Is Too Big to Estimate

When a team plays 21 or "too big" cards, most facilitators treat it as a problem to solve. It's actually a gift: the team is telling you this story isn't ready to deliver.

What "too big" actually means

A story is too big for one of three reasons:

1. Scope is genuinely large. The feature is real but encompasses too much work for one sprint.
2. The approach is unknown. Nobody knows how to build it yet, which makes the estimate meaningless.
3. The story is vague. The acceptance criteria are so unclear that each person is imagining a different story.

The solution is different for each.

Splitting by scope

For stories that are large but well-defined, split along delivery value: "What's the smallest version of this that delivers real value to a user?" That's your first story. Everything else is follow-on work.

Splitting patterns that work:

• By user type: story for admin users first, regular users second
• By data source: handle the simple case first, edge cases separately
• By workflow step: first half of a flow, second half separately
• By happy path vs. error handling: core flow first, error states later

Splitting by unknown approach

If the "too big" vote comes from uncertainty about how to build it, that's a spike. Time-box an investigation and come back with a refined story after discovery.

Splitting vague stories

If nobody can agree because nobody knows what the story means, that's a Product Owner problem. Park the story and refine the acceptance criteria before the next session.

When not to split

Don't split a story just to hit a point threshold. A story that's genuinely 8 points should be an 8-point story. Artificial splitting creates coordination overhead without reducing complexity.

A story that can't be estimated can't be delivered reliably. Use the vote as the trigger to do the work that makes it estimable.