How to cut big work into thin pieces that are each worth having (slicing), how a team agrees how big each piece is (sizing), and why both matter more than they look. About 12 minutes to read.
Think of a layered cake: sponge at the bottom, cream in the middle, icing on top. Serve it layer by layer and the first guest gets a plate of plain sponge. Cut a slice downwards and every guest gets all three layers in one small piece. Work is the same.
In software, the layers are typically the screens, the business rules and the database. In other kinds of work they might be research, drafting and approval. A horizontal piece finishes one layer for everything. A vertical slice goes through every layer for one small thing, so it works from end to end.
Value only arrives when something is finished. Slicing is how we make "finished" happen every few days and not every few months.
Take this request: "Customers can pay for their order online." It is far too big for one card. Here are common ways to cut it.
| Slice by… | Ask yourself | Example slices |
|---|---|---|
| Steps in the journey | Can one step work on its own first? | Enter card details, then show a confirmation page, then send an email receipt |
| Simplest case first | What is the simplest version that still works? | One item and full price first; discounts and vouchers later |
| Options | Can we support one option now and add the others later? | Card first, then PayNow, then instalments |
| Business rules | Which rules can wait? | Singapore dollars first; other currencies and tax rules later |
| Type of user | Who needs it most? | Returning customers first, then guest checkout |
| Good path, then problems | What if everything goes right? | Successful payment first; declined cards and time-outs next |
| Learn first (a "spike") | What do we not know yet? | Two days trying out the payment provider before sizing the rest |
Someone could use it, or at least see it working, even if nothing else were ever built.
It goes through every layer it needs. Nothing is left "waiting for the back end".
It fits comfortably inside one Sprint. Ideally it is a few days of work.
It has clear acceptance criteria, so everyone knows when it is done.
Many teams use the INVEST checklist for this: Independent, Negotiable, Valuable, Estimable, Small, Testable.
| Mistake | What goes wrong |
|---|---|
| Slicing by layer ("build the database", "build the screens") | Nothing works until every card is done. There is nothing to show, and problems appear only when the layers meet. |
| Slicing by phase ("design", "build", "test") | It is a mini-waterfall. Testing piles up at the end of the Sprint. |
| Slicing by person ("Sam's part", "Priya's part") | Work waits on hand-overs, and nobody owns the whole result. |
| "Part 1" and "Part 2" | The cut is arbitrary. Part 1 delivers nothing by itself. |
| Slicing too thin | Dozens of tiny cards that mean nothing to a user. Stop cutting while a slice still delivers something visible. |
Slicing cuts work into small pieces so that each one can be built and checked on its own. Splicing is the other half: joining those pieces back together and checking that the whole thing works. Think of a burger shop.
Every ingredient can pass its own check and the burger can still fail. Two salty things together are too salty. A juicy patty turns a soft bun soggy. A tall stack falls apart in the customer's hands. These problems live in the joins, so only the assembled burger can show them.
| Slicing | Splicing | |
|---|---|---|
| The question | "Is this piece right?" | "Do the pieces work together?" |
| In the burger shop | Taste the patty, the sauce and the bun separately | Take a bite of the assembled burger |
| In a team | One card is built, reviewed and tested against its acceptance criteria | The card is joined to everything else and the whole product is tried from end to end |
| What it catches | Mistakes inside one piece | Mistakes between pieces |
| When | As each piece is finished | Straight afterwards, every time, not once at the end |
Do not save the splicing for the end: preparing ingredients for weeks and assembling the first burger on opening day is waterfall all over again. See Building sustainably.
In software teams, splicing usually goes by the name "integration". Doing it many times a day is called continuous integration.
Sizing is the team asking "roughly how big is this, compared with things we have done before?". It is rough on purpose. The aim is a good-enough answer in two minutes, not a perfect answer in two hours.
What sizing is not: a promise, a deadline or a score. The moment sizes are used to judge people or to compare teams, people inflate them and the numbers stop meaning anything.
Ask how many hours a task will take and you get a different answer from every person, usually an optimistic one. Ask whether it is bigger or smaller than a task finished last week, and people agree quickly. Humans are poor at absolute estimates and good at comparisons.
So teams size in story points: a number that only means "bigger or smaller than our other work". Pick one card everybody understands well and call it a 2. A card that feels a little more than twice as big is a 5. Points cover three things at once: how much there is to do, how hard it is, and how much we do not know yet.
Most teams use the numbers 1, 2, 3, 5, 8 and 13 (the Fibonacci sequence). Some prefer T-shirt sizes (S, M, L, XL), which work in the same way.
Only the people who will do the work size the work. The Product Owner explains and answers questions, but does not vote.
| Mistake | What goes wrong |
|---|---|
| Converting points to hours ("1 point = 1 day") | You are back to absolute estimates, with an extra step. |
| Using velocity as a target | Sizes inflate, velocity "improves" and nothing actually gets faster. |
| Comparing teams by their points | Each team's points are its own private scale. The comparison means nothing. |
| A manager or lead sizes for the team | The people doing the work miss the conversation, and do not feel the commitment is theirs. |
| Debating a 3 versus a 5 for twenty minutes | The precision is false. Take the larger number and move on. |
| Changing the size after the work is done | It hides how wrong we were, and that is exactly what we need to learn from. |
| Sizing work nobody understands yet | A number on a vague card is a guess about a guess. Clarify it or run a spike first. |
Good to know: the Scrum Guide does not require story points, Planning Poker or any other method. It only says that the people doing the work are responsible for sizing it. Some experienced teams skip points altogether: they slice everything to roughly the same small size and simply count cards.
Sizing tells you when to slice, and slicing makes sizing easy. A common team rule: anything bigger than an 8 gets sliced before it can enter a Sprint.
| When | What happens |
|---|---|
| 🧹 Refinement | Big items are sliced and sized. Most of the work happens here. |
| 🗓️ Sprint Planning | The team uses the sizes and its usual pace to decide how much fits. |
| ☀️ During the Sprint | If a card turns out far bigger than expected, say so at the Daily Scrum and slice it. |
| 🔁 Retrospective | Look back at the cards that surprised us. What did we miss, and how will we spot it next time? |
These questions fit well into a Definition of Ready. See Ready and Done in the Scrum guide.