To estimate a large epic, give it a rough size first (a T-shirt size or a big Modified Fibonacci number like 40), then split it into user stories small enough to estimate properly, ideally 8 points or less each. A 13-point story is usually too big for a sprint: it's the point where unknowns start to dominate, and splitting it almost always reveals work nobody had counted.
This guide covers how to tell a story is too big, seven splitting patterns with examples, a worked example of splitting a 40-point epic, and a short workshop format to do it as a team.
Two levels of estimation
Epics and stories need different kinds of estimates, and mixing them up causes most of the pain.
| Epic estimate | Story estimate | |
|---|---|---|
| Purpose | Roadmap ordering, rough "is this a month or a quarter?" | Sprint planning, velocity |
| Scale | T-shirt (S to XXL) or 20/40/100 | Fibonacci 1 to 8 (13 at most) |
| Precision expected | Very low; can easily be off by half or double | Reasonable when compared to references |
| When | Before splitting, often months ahead | During refinement, a sprint or two ahead |
| Who | Team leads and PO can do a quick pass | The whole team doing the work |
Don't spend an hour of planning poker on an epic. Give it a fast, rough size so it can be ordered on the roadmap, and save careful estimation for the stories you split out of it. Fibonacci vs T-shirt sizing has a mapping between the two scales.
Is a 13-point story too big?
In most teams, yes. Thirteen is the size at which a story usually has more than one meaningful unknown, can't be finished by one or two people in a few days, and carries a real chance of rolling over. Some teams with high velocity can absorb a 13 occasionally. As a rule of thumb: 13 means discuss splitting; 20 or more means split before sprint planning.
Other signs a story is really an epic:
| Signal | What you'll hear or see |
|---|---|
| Wide vote spread | Votes like 5, 8, 21, ? on the same story |
| Many "it depends" | "Depends which carrier, depends on the mobile design, depends on finance" |
| Long acceptance criteria | More than six or seven criteria, often covering different users |
| Multiple roles in one story | "As a customer and an admin and a support agent..." |
| The word "and" in the title | "Import contacts and deduplicate and merge" |
| Unresolved architecture | Team debates the approach rather than the size |
| Doesn't fit in half a sprint | Nobody can picture it done in a few days |
Seven patterns to split user stories
These patterns are adapted from widely used splitting guides (Richard Lawrence's story-splitting patterns are a good longer reference). The goal is always a vertical slice: each new story still delivers something a user or stakeholder can see and test.
1. Workflow steps
Split along the steps a user goes through. Deliver the simplest end-to-end path first, then add steps.
Epic: "Customer onboarding."
- Sign up and verify email
- Set up profile
- Guided first-project tutorial
- Invite teammates
2. CRUD operations
When a feature manages something, split by Create, Read, Update, Delete. Read is often the most valuable to ship first.
Epic: "Admin user management."
- View and filter user list
- View user details
- Edit roles and permissions
- Deactivate users
3. Business rules
Ship the core rule first, then add the variations as separate stories.
Epic: "Discount codes at checkout."
- Apply a fixed-amount code
- Percentage codes
- Minimum order value rule
- One-use-per-customer rule
- Codes that exclude sale items
4. Data variations
Handle one type of input or data first, then extend.
Epic: "Import contacts."
- Import from CSV with fixed columns
- Column mapping for arbitrary CSVs
- Import from Excel
- Import from Google Contacts
5. Happy path, then edge cases
Get the successful case working, then add failure handling.
Epic: "Card payments."
- Successful card charge
- Declined card handling
- Retry on network timeout
- Refunds
6. User roles
When different people use the same feature differently, split by who.
Epic: "Reporting dashboard."
- Team lead view
- Individual contributor view
- Executive roll-up
7. Spike first
When you can't split because you don't know enough, run a timeboxed spike. The spike's output is information and a set of split stories, not production code. This is the right pattern when uncertainty, not size, is what makes the epic hard to estimate. Complexity vs effort in story points explains how to tell the difference.
Epic: "Integrate with new shipping carrier."
- Spike (2 days): create a label in the carrier sandbox, confirm rate limits and webhook behavior, list required data fields
- Then split using the patterns above
Which pattern should you use?
| If the epic... | Start with |
|---|---|
| Has a clear sequence of user steps | Workflow steps |
| Is mostly managing records | CRUD |
| Has lots of "if X then Y" rules | Business rules |
| Accepts many input formats or sources | Data variations |
| Is risky or failure-prone (payments, integrations) | Happy path, then edge cases |
| Serves very different users | User roles |
| Can't be split because nobody knows enough | Spike |
Patterns combine. You might split by workflow step, then split one step by business rule.
Worked example: splitting a 40-point epic
Epic: "Customers can return items online."
In roadmap planning, the team sized it as XL, which on their Modified Fibonacci deck is a 40. That number was enough to put it in next quarter's plan, but nobody could commit to it in a sprint.
Step 1: Split by workflow
The PO walked through what a customer does:
- Choose an order and items to return, pick a reason
- Get a prepaid shipping label
- Warehouse receives the package and marks it inspected
- Customer gets refunded
Step 2: Find the risky part and spike it
Step 2 needed the carrier's label API, which the team had never used. Votes on "get a shipping label" came back 3, 8, 13, ?. The team created a two-day spike. Findings: the API worked, but labels needed a validated address and the carrier rate-limited bulk requests.
Step 3: Split further by business rules and data variations
Discussion uncovered rules nobody had written down: a 30-day return window, final-sale items can't be returned, and orders with gift cards refund differently. International orders need a customs form.
Step 4: Estimate the stories
| # | Story | Pattern | Points |
|---|---|---|---|
| 1 | Customer selects order items and return reason (domestic, card-paid orders, within 30 days) | Workflow + business rule | 5 |
| 2 | Block returns for final-sale items and orders over 30 days | Business rule | 2 |
| 3 | Generate prepaid domestic label after address validation | Workflow (post-spike) | 5 |
| 4 | Warehouse marks return received and inspected | Workflow + role | 5 |
| 5 | Automatic refund to original card on inspection | Workflow | 5 |
| 6 | Refunds for orders paid partly with gift cards | Data variation | 5 |
| 7 | Return emails: label sent, received, refunded | Workflow | 3 |
| 8 | Admin view of all open returns with status filter | CRUD (read) + role | 5 |
| 9 | International returns with customs form | Data variation | 8 |
| Total | 43 | ||
| Spike: carrier label API (timeboxed, not pointed) | Spike | 2 days |
Step 5: Decide what ships first
The team didn't need all nine stories to deliver value. Stories 1 to 5 and 7 make a working domestic return flow: 25 points, about one sprint at their velocity of roughly 28. Stories 6, 8, and 9 were ordered by the PO for the following sprint, and international returns (the only 8) was flagged as the first candidate to drop if the quarter got tight.
What the example shows
- The total went up, from 40 to 43. That's normal. Splitting surfaces rules and variations that were invisible at epic level. If your split totals are consistently much higher than your epic estimates, inflate future epic estimates or size epics in T-shirts and stop pretending they're precise.
- No story is above 8. Every item can be finished inside a sprint, and the only 8 is the one with the most remaining variation.
- The spike turned a "?" into a 5. Uncertainty was the problem, not size.
- Splitting created choices. A 40-point blob is all or nothing. Nine stories let the PO ship the core in one sprint and decide later about the rest.
A 60-minute splitting workshop
Use this in a backlog refinement session when an epic is coming up in the next sprint or two.
| Time | Step | Facilitator prompt |
|---|---|---|
| 5 min | PO presents the epic and the outcome it's for | "What problem does this solve, and for whom?" |
| 10 min | Walk the workflow end to end | "What does the user do first? Then what?" |
| 15 min | Silent brainstorm of stories on sticky notes or a shared board | "Write one slice per note. Each must be something we could demo." |
| 10 min | Group, deduplicate, label with a splitting pattern | "Which of these are rules? Which are data variations?" |
| 15 min | Quick planning poker on each story | "Anything that comes back above 8, we split again or spike." |
| 5 min | PO orders them; mark the smallest valuable first release | "If we only shipped the top three, would anyone use it?" |
If you're doing this remotely, a shared board for the brainstorm and free planning poker for the estimation step are enough. Alignlee's Modified Fibonacci deck includes 20, 40, and 100 for rough epic sizing alongside the usual 1 to 13.
How small is small enough?
Most teams aim for stories between 1 and 8 points. A useful check for each story:
- It can be finished, tested, and demoed within one sprint, comfortably
- It delivers something a user or stakeholder can see or verify
- It has clear acceptance criteria (three to five is typical)
- One or two people could own it end to end
- The team agrees on its estimate within one revote
If several stories are 1s, that's fine. Small stories flow better than large ones. The user story readiness checklist has a fuller list.
Common splitting mistakes
Horizontal slicing. "Story 1: database. Story 2: API. Story 3: UI. Story 4: testing." None of these deliver anything on their own, and they create a chain of dependencies. Split so each story cuts through every layer for a small piece of behavior.
Slicing into tasks. "Add a save button" is a task, not a story. If a slice has no value on its own, merge it back into its parent.
Splitting to hit a number. "It's a 13, let's make two 5s." Split along functional boundaries; the numbers follow.
Keeping the epic's estimate. Once the stories exist and are estimated, the epic's size is their sum. Don't keep reporting the original 40.
Splitting too far ahead. Stories split six months early go stale. Split the epics that are coming up in the next sprint or two; keep the rest at T-shirt level.
Skipping the spike. If the team can't agree on how to split, the problem is usually missing information. Spike rather than guessing.
FAQ
How do you estimate large epics in agile?
Give the epic a quick rough size, such as a T-shirt size or 20/40/100 on a Modified Fibonacci deck, so it can be placed on the roadmap. Then split it into user stories of 8 points or less and estimate those with planning poker. The real estimate is the sum of the stories, which is often larger than the original rough size.
Is a 13-point story too big?
Usually. A 13 typically contains multiple unknowns and is at risk of rolling over. Treat 13 as a prompt to discuss splitting, and split anything at 20 or above before sprint planning. Teams with very high velocity may occasionally accept a 13 if it's well understood.
How do you split user stories?
Use a splitting pattern that keeps each story a vertical slice: workflow steps, CRUD operations, business rules, data variations, happy path then edge cases, or user roles. If you can't split because the work is too unknown, run a timeboxed spike first and split based on what you learn.
Why did our estimate go up after splitting the epic?
Splitting exposes rules, edge cases, and variations that weren't visible at epic level. An increase of a few points is normal and means the estimate got more honest. If increases are consistently large, size epics more conservatively or keep them in T-shirt sizes until they're split.