The business says this story cannot be delivered in parts. How do you split it anyway?

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.