“Build checkout” is too large to be a useful delivery conversation. Splitting it into “build the database,” “build the screen,” and “test checkout” makes the work smaller, but none of those pieces lets a customer buy anything on its own.
A better split is a narrow purchasing path that works from beginning to end. Use a shared Scrum planning board to compare those slices, their acceptance examples, and the work deliberately left for later. Keep the customer outcome visible while engineers discuss the tasks needed to support it.
Is this a smaller story or just a technical task?
The Agile Alliance definition of story splitting keeps business value in each smaller story. That does not mean a slice must be a complete commercial launch. It means the result can demonstrate a useful change in behavior, rather than only the completion of one technical layer.
A user can complete a purchase, retrieve a saved order, or apply an eligible discount. A user cannot meaningfully “use the database table” without the surrounding behavior. Database changes, interface work, and tests remain necessary; put them underneath the story as implementation work instead of relabeling them as independent customer outcomes.
Vertical slicing refers to a thin path through the necessary parts of the system. It does not mean that every story must be physically drawn as a vertical column. The Humanizing Work guide to splitting stories explains this distinction and provides patterns for reducing scope while keeping useful behavior.
Set the checkout example's boundary
Imagine a shop that already lets customers browse available products and place items in a cart. The team now needs checkout. Its initial request includes several payment methods, multiple delivery regions, discount codes, saved addresses, and guest accounts. Those are not all needed to learn whether a first purchasing path works.
For this hypothetical release, the team selects existing registered customers buying available products for delivery within one supported region. It will offer one supported payment method and the existing standard delivery option. It will not support coupons, saving addresses for future orders, or international delivery yet.
The first slice reads: “A registered customer can purchase the available items in their cart using the supported payment method and receive an order confirmation.” The boundary is narrower, but the customer still completes a purchase.
Compare two ways to divide the work
| Component-based division | Why it is not enough | Customer-facing slice |
|---|---|---|
| Create the order database. | There is nowhere for a customer to place an order. | Complete a standard purchase and record the order. |
| Build the payment screen. | A screen without the transaction and order behavior cannot confirm a purchase. | Pay using the first supported method; receive a clear accepted or rejected result. |
| Add discount calculation. | A calculation by itself is not an end-to-end discount experience. | Apply one agreed discount rule to an otherwise working checkout. |
| Build an address table. | Storing addresses does not show that a customer can select one and complete delivery details. | Choose a saved address during an otherwise working purchase. |
The right-hand items are not a commitment to four separate releases. They are candidate slices the team can discuss and order. The first two rows may belong to the same initial story because a successful purchase includes payment handling. Do not split them apart merely to produce more cards.
Make the first slice testable
Write examples before calling the slice “small enough.” A happy-path sentence can hide the work that makes the behavior usable. The checkout acceptance criteria example turns one order-review story into observable conditions and test scenarios, while keeping its scope separate from the team’s Definition of Done.
| Situation | Expected behavior | Scope decision |
|---|---|---|
| The customer has available items and supplies valid supported payment details. | The order is recorded, the customer sees confirmation, and the order reference identifies that purchase. | Included in the first slice. |
| The payment is rejected. | The customer sees that the purchase was not confirmed and can correct the payment attempt. | Included; failure handling is part of the purchasing path. |
| The customer submits again while the result of the first attempt is unclear. | The system does not create a duplicate purchase merely because the action was repeated. | Resolve the required behavior with engineering before accepting the slice. |
| An item is no longer available when checkout is attempted. | The customer is told which item prevents completion rather than receiving a misleading success message. | Included; availability must be checked at the relevant point. |
| The customer wants an unsupported payment method or delivery region. | The available options are clear; an unavailable option is not presented as working. | Additional methods and regions remain later work. |
These examples describe desired behavior, not a payment implementation specification. The team's existing security, accessibility, privacy, and release requirements still apply. Removing necessary safeguards or error handling is not the same as reducing business scope.
Choose the next slice by the uncertainty it resolves
Once the standard purchase works, the team has several possible next steps. Supporting another payment method expands who can pay. A discount rule changes price calculation and the explanation shown to customers. Saved addresses reduce repeat entry for returning customers. Each answers a different need; none must automatically come next.
Ask which customer group is blocked and what evidence shows the blockage. If the supported region contains the intended pilot audience, international delivery may be less urgent than correcting a confusing confirmation. If the payment method excludes that audience, the original first slice may have been chosen badly.
Also separate discovery from delivery. A short investigation into an unfamiliar payment provider can reduce technical uncertainty, but it is not itself a completed purchasing story. Give it a clear question and expected evidence; do not disguise it as customer value by starting the sentence with “As a user.”
Arrange the slicing conversation in Boardmix
Place the oversized checkout request at the top of a Boardmix board. Below it, create areas for the first usable slice, later options, and unanswered questions. Keep technical tasks under the slice they enable, not in a competing list of supposed user stories.
For the first slice, add the acceptance examples beside its card. Put “duplicate submission behavior” in the questions area until the team agrees on the expected result. Connect it to the affected story so the uncertainty is visible when the story is discussed.
A user story map is useful when you need to place this checkout work within the wider shopping journey. The slicing board answers a narrower question: what is the smallest useful change we can make inside this part of that journey?
Before moving the chosen story into your team's delivery system, read its outcome and examples together. If the only demonstrable result is that one technical layer exists, keep looking for a smaller end-to-end behavior. Open Boardmix to lay out the candidate slices and make that comparison with your team.
