Most stories that miss the sprint were too big, vague, or both — and that was visible at refinement. Four artifacts to fix it: write to INVEST, split when it carries over, size relative not absolute, and write acceptance criteria that catch hidden scope.
Three failure modes account for most carry-over: stories too big to finish in a sprint (no split applied), acceptance criteria that hid scope (a "yes but also…" found mid-sprint), or estimates anchored on hours not relative size. The toolkit attacks each one with a separate artifact.
Independent, Negotiable, Valuable, Estimable, Small, Testable. Side-by-side examples of stories that fail each criterion and the fix. Not theory — the rewrite.
Story too big to finish in one sprint? Pick a split pattern (workflow, business rules, happy/sad path, data variation, interface variation) and get the split stories. Copy as markdown.
Relative sizing without the planning-poker overhead. Compare against reference stories on three axes (effort, complexity, uncertainty), get a Fibonacci point. Calibrates per team.
Given/When/Then vs bullet AC vs example-based. When each format fits, the hidden-scope-creep patterns to watch, and the anti-patterns ("system shall…", scope-by-omission).
The gate that catches not-yet-ready stories before they enter a sprint. Five criteria, what to refuse, how DoR fits with refinement.
ReadThe session where stories get written, split, and sized — done well. The runbook, two anti-patterns, what should never happen in the meeting.
ReadWhy Fibonacci, why relative, what counts as a "1", and the four estimation anti-patterns (anchoring, points-as-hours, average-vote, re-estimation).
ReadThe actual difference, four blurring patterns (wishlist sprint, sprint queue in backlog, mid-sprint dumps, refinement-at-planning), the fix.
ReadSprintFlint has story management built in — INVEST checks at story creation, split-suggestions for too-big stories, relative-sizing UI, and AC fields with format hints. The toolkit, but in your sprint workflow.