Two different objections are being made at once
Almost every "this cannot be split" is really "this cannot be released in parts", and those are
separate claims that deserve separate answers. A payroll change that goes live on 6 April must go
live whole; a regulator's return that is either submitted or not cannot be two-thirds submitted.
That is a constraint on release, and it is usually legitimate.
It says nothing about how the work is built, integrated, tested and reviewed on the way there.
The point of splitting is to get feedback and reduce the size of the thing that can be wrong,
not to ship half a feature to users. Once you separate the two, the conversation moves from
whether to split to how, and the release constraint is satisfied by keeping the incomplete slices
switched off rather than by building for eleven weeks in one lump.
The second thing to test is whether the objection is really about size at all. Sometimes the
stakeholder is defending against a fear you can address directly: that a partial delivery will
be declared finished and the remainder quietly dropped, which is a reasonable fear if it has
happened to them before. That is answered with a visible plan for the whole set and a written
commitment to the release condition, not with a slicing technique.
Slice on business dimensions, and pick the one that removes the most doubt
The dimensions that produce useful slices are all business-facing. Take a single fat story —
employees submit expense claims online, with approval, policy checking and payment — and the
candidate splits look like this.
| Dimension | Slice you build first | What it buys you |
|---|
| Workflow step | Submit and store a claim, with approval still done by email | Proves the capture form against real claims within a fortnight |
| Rule variation | Single-currency claims under the delegated limit only | Defers the two rules that need finance sign-off, and they are the ones still in dispute |
| Segment | One department of eighty people | A real pilot with a named owner, and a rollback that affects eighty rather than nine thousand |
| Happy path versus exception | Claims with a valid receipt attached; everything else goes to the existing manual queue | The exception paths are 15 per cent of volume and most of the complexity |
| Manual before automated | Payment file produced as a spreadsheet a clerk uploads | Removes an integration from the critical path without removing the outcome |
Which one to take first is a judgement, and the judgement is what an interviewer is grading. Pick
the slice that resolves the largest uncertainty for the least build: if the risk is that nobody
will use the form, do the capture slice with one department; if the risk is that the policy rules
are wrong, do a narrow rule set over real historical claims. Splitting to make sprint arithmetic
work is bookkeeping. Splitting to learn something early is analysis.
Slicing by layer looks like splitting and is not
The version that fails is the tempting one: a story for the database changes, one for the
service, one for the screen. It fits neatly into a sprint and it delivers nothing. Nobody can
review it, no user can react to it, no test can exercise the behaviour, and the integration risk
you most wanted to expose stays hidden until the last of the three lands. Worse, if priorities
move after the first two, you are left with schema and endpoints that serve no purpose and will
be maintained for years.
The test to apply to each proposed slice is whether you could stand up at review and show a
business person something they recognise as their own work being done, even in a narrow case. If
the answer is no, you have divided the task list rather than sliced the value, and the fat story
is still fat.
The genuinely atomic case
Occasionally the work really is indivisible: one legal calculation, one algorithm, one contract
term that either holds or does not. Say so rather than forcing a split to satisfy a rule, and
then manage the risk by other means. Build a walking skeleton that runs the calculation over
last year's real cases and reconciles against the current system's output, so the answer is
being checked from week one. Order the acceptance criteria and get them tested as they complete
instead of all at the end. Timebox a spike on the part nobody understands, with a decision
scheduled at the end of it.
That is the answer that separates a strong candidate here. Insisting that everything can be
split is as unconvincing as accepting that nothing can, and knowing which case you are in — with
a reason — is the actual skill.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).