Split large backlog items into small stories and estimate them with story points and planning poker.
Why it matters
A sprint can only go well if the items going into it are understood, small enough to finish and roughly sized. Getting them there is Product Backlog refinement: the ongoing work of breaking items down, adding detail and estimates, and reordering. The Scrum Guide calls it an ongoing activity rather than an event; many teams hold a regular one-hour session each week. Analysts and designers often lead the preparation.
What a ready backlog looks like
A healthy Product Backlog is shaped like an iceberg, sometimes described with the acronym DEEP:
- Detailed appropriately: items near the top are small and clear; items further down can be rough.
- Estimated: the top items have sizes.
- Emergent: it changes as the team learns.
- Prioritised (ordered): the most valuable work is at the top.
Many teams agree a Definition of Ready: for example, the item has a clear user story, acceptance criteria, no unresolved dependencies, and the team has sized it. Use it as a guide, not a gate that stops all conversation.
Splitting stories
Big items (epics) must be split until each piece fits comfortably in a sprint, ideally several per sprint. The key is to split vertically: each piece is a thin slice through every layer (screen, logic, data) that a user can actually use. Splitting horizontally ("build the database", "build the screens") produces pieces that deliver no value alone.
Useful splitting patterns, using Northside Sports Centre's epic "Members can book activities on the app":
| Pattern | Split into |
|---|---|
| Workflow steps | Browse free slots; book a slot; cancel a booking |
| Business rules | Book any free court; then add "members may hold at most 3 future bookings" |
| Data types | Courts first; classes later (classes have capacity and instructors) |
| Happy path first | Book with no problems; then handle "slot taken while you were booking" |
| Interface | Phone app first; desktop later |
| Simple then complex | Pay at the desk; then pay in the app |
After splitting, check each story against INVEST (independent, negotiable, valuable, estimable, small, testable), covered in Business & Systems Analysis.
Estimating with story points
Teams usually estimate in story points: a relative measure of effort, complexity and uncertainty together. A 2-point story is roughly twice the work of a 1-point story; points are not hours. Relative sizing works because people are much better at comparing ("this is about twice that") than at predicting absolute time.
Most teams use a modified Fibonacci scale: 1, 2, 3, 5, 8, 13, 20. The growing gaps reflect growing uncertainty. Anything above 13 is usually a sign the item should be split.
Planning poker
- The Product Owner reads a story and answers questions.
- Each developer privately picks a card with their estimate.
- Everyone reveals at the same time, so nobody anchors on the loudest voice.
- If estimates differ widely, the highest and lowest explain their reasoning.
- Re-vote until the team converges, usually in two or three rounds.
The discussion is the real value. If one person says 2 and another says 13 for "Cancel a booking", one of them knows something: perhaps a refund rule, perhaps an existing feature that makes it easy. Either way the team learns before building.
A worked refinement
Story Votes Result
Browse free courts for a day 3 3 5 3 3
Book a free court 5 5 5 8 5
Cancel a booking (refund rule unclear) 2 13 5 8 -> discuss: full refund up to 24h before
5 5 5 5 5
Limit of 3 future bookings per member 2 2 3 2 2
Book a class (capacity, waiting list) 13 20 20 13 -> too big, split into "book class" and "waiting list"
Other estimation options
- T-shirt sizes (S, M, L, XL) for rough sizing far down the backlog.
- Affinity estimation: lay all cards on a table and group them by relative size; fast for many items.
- No estimates: some Kanban teams skip sizing and simply split everything to roughly similar small sizes, then forecast from throughput.
Common mistakes
- Converting points to hours or comparing points between teams. Points only mean something within one team.
- Horizontal splits that deliver nothing usable on their own.
- Refining too far ahead: detailed stories for work six months away go stale.
- The Product Owner estimating. The people doing the work estimate it.
Quick recap
- Refinement keeps the top of the backlog small, clear, estimated and ordered.
- Split vertically using workflow, rules, data, happy path or interface patterns.
- Story points are relative; use a Fibonacci-like scale and split anything very large.
- Planning poker reveals hidden knowledge through discussion of different estimates.
Try it
Open the Do tab and refine a small backlog with planning poker.