Signs that an item is too large
A large item is not automatically bad, but it is hard to estimate usefully. Watch for repeated high cards, votes spread across most of the deck, frequent ? votes, or discussion that jumps between several unrelated outcomes. Those signals usually mean the item contains multiple decisions or unknowns.
Split by user outcome
If the story describes a broad capability, split it into narrower outcomes a user can experience. "Manage notifications" might become "choose email notifications," "pause notifications," and "preview notification text." Each slice should still produce something testable, not just a technical layer.
Split by rule or scenario
Business rules often create natural boundaries. A first slice can support the most common path, while later slices add exceptions, permissions, edge cases, or alternate states. This helps the team estimate known work separately from uncertain policy details.
Split by data or integration risk
Integrations, migrations, and reporting often hide the biggest uncertainty. Consider separating discovery, read-only integration, write behavior, error handling, and operational monitoring. The team can then estimate the risky part directly rather than burying it inside a broad feature estimate.
Avoid fake splits
Splitting "frontend," "backend," and "tests" may make tasks smaller, but it often removes the user outcome and makes prioritization harder. Prefer vertical slices that can be demonstrated, validated, or deliberately deferred. Technical tasks still have a place, especially for discovery or infrastructure, but they should not be the only way a team makes work smaller.
Use estimation to validate the split
After splitting, run planning poker again on each candidate slice. If estimates are still widely spread, the split probably did not address the source of uncertainty. If the conversation becomes shorter and more concrete, the new shape is likely easier to plan.