Story Splitting: How To Split User Stories So Teams Can Finish

Every team has had this sprint review.

The team worked hard. The most important story got plenty of attention. Everyone agrees progress was made.

But there’s not much to show.

The backend is done, but the UI isn’t connected. The main flow works, but the edge cases aren’t tested. The feature is close, but no one is comfortable calling it done.

So the story moves to the next sprint.

When that happens occasionally, it may just be bad luck. When it happens regularly, start by looking at story size.

Big stories are hard to finish. They stay in progress for days, sometimes for the entire sprint. They create the illusion of progress because everyone is busy. But by the end of the sprint, too much work is still almost done.

Story splitting helps teams avoid that. It turns large backlog items into smaller user stories that still represent meaningful progress toward a user, business, or product outcome.

The goal is not to create more backlog items. The goal is to help the team finish.

What Is Story Splitting?

Story splitting is the practice of breaking a large user story into smaller user stories that still represent meaningful progress toward an outcome.

That outcome might be visible to a user, helpful to the business, reduce risk, or help the team learn something important. But a split story should still move the product forward.

Story splitting is different from breaking work into tasks.

Tasks describe activities: design this, code that, test this other thing. Stories describe outcomes. A good split preserves that distinction.

A story that says, “Build the payment backend,” is really a task masquerading as a story.

A story that says, “A customer can pay by credit card using the happy path,” is a better split. It narrows the capability while still delivering something that works end to end.

Why Teams Split User Stories

Teams split stories so they can finish them within an iteration.

Software work is notoriously hard to assess by percentage complete. A developer may sincerely believe a story is 90% done. A week later, after discovering more complexity, that same developer may still sincerely believe the story is 90% done.

This is known as the 90% syndrome: software is 90% done for 90% of the schedule.

The problem usually isn’t that people are being dishonest. It’s that big work is hard to measure while it’s in progress.

Agile teams make this easier by making work small enough that each item can move cleanly from not started to done. We’re not very good at knowing whether a big story is 60%, 75%, or 90% complete. We’re much better at knowing whether a small story is done.

As a rough guide, be wary of bringing a story into a sprint if it could consume half or more of the sprint. That’s not a target. It’s a warning sign.

Good teams usually work with much smaller stories. That lets them finish throughout the sprint instead of waiting for one large item to come together at the end.

Split By Value, Not By Technical Layer

The most common mistake teams make is splitting stories by technical layer.

They take a large story and create separate stories for the user interface, backend, database, testing, or design. That may look smaller on the board, but it rarely helps the team finish anything meaningful.

Each item depends on the others. Nothing can be demonstrated as a working user flow. The team has divided the work, but not the value.

A better split cuts vertically through the work. It includes enough of the user interface, backend, database, testing, and other necessary parts to support a narrower outcome.

Consider a team building a home search feature. The large story might be:

As a prospective home buyer, I can search for a home based on size, number of rooms, status, type of home, age, and amenities.

A poor split would be:

• Build the search user interface
• Build the search backend
• Build the database query
• Test the search feature

Those are tasks and technical layers. None of them gives a home buyer a working search capability.

A better split might be:

• A prospective home buyer can search by size and number of rooms.
• A prospective home buyer can add property status and type of home to the search.
• A prospective home buyer can add age of the home and amenities to the search.

Each smaller story includes the work needed to make that narrower search function work.

The first version may be plain. It may support only a few fields. But it works for the fields it supports. That gives the team something done, testable, and demonstrable.

That’s the point of story splitting: Do something smaller but make it valuable.

Story Splitting Is Different From Task Splitting

Splitting work into tasks has its place.

During sprint planning, a team will break a story into tasks such as coding, testing, reviewing, designing, or updating documentation.

But that’s not story splitting.

Tasks are generally one-person activities. They’re helpful for organizing how the team will do the work.

Stories, on the other hand, require collaboration. A story usually needs analysis, design, development, testing, and feedback to come together around a useful outcome.

When a team splits a large story, the goal is to create smaller stories that still require that collaboration.

A quick test helps:

• If the item describes one activity someone will perform, it’s probably a task.
• If the item describes a smaller capability, outcome, or learning step, it may be a story.

“Create database tables for payments” is a task.

“A customer can pay with one payment method on the happy path” is a story.

What Makes A Good Story Split?

A good split is small enough to finish, valuable enough to matter, and complete enough to test.

A Good Split Is Outcome-Oriented

A good split produces a coherent outcome for someone.

After the story is done, a user, internal employee, system, or business process can do something it couldn’t do before.

If the story is “backend for X” or “UI for X,” the team is probably looking at a task. If the story allows someone to complete a narrower version of X, the team is closer to a useful split.

A Good Split Delivers Value, Or At Least Creates It

Not every small story will be valuable enough to release immediately. That’s OK. The split should still create value.

A story might create value by adding functionality, reducing risk, validating an assumption, or making progress toward a larger capability.

The key is that the story should represent meaningful progress, not merely activity.

For example, a team building time-off approval functionality might discover an edge case: some employees require two managers to approve a request. Supporting that edge case could make the story two or three times larger.

A good split would support the normal case first: an employee has one manager who can approve the request. The two-manager edge case can come later.

The first story may not be releasable without the edge-case functionality. But the team created value by developing it because it completes a useful part of the overall capability.

A Good Split Is Small Enough To Finish

A good split should fit comfortably within a sprint. Ideally, it should be much smaller than the whole sprint.

When one story consumes most of the sprint, the team has very little room for discovery, feedback, or surprise.

Small stories make progress visible. They also give the team more opportunities to finish, review, and adjust.

A Good Split Is Vertical

A good split usually cuts through all the layers needed for a narrow outcome.

That might include a little database work, a little API work, a little user interface work, and enough testing to prove the behavior works.

The team is not trying to complete every layer for the entire feature. It is completing the necessary layers for a smaller scenario.

A Good Split Is Clear And Testable

A good split has acceptance criteria that can be verified without waiting for several other unfinished stories.

Someone should be able to look at the story and know what must be true for this item to be considered complete.

The criteria should describe behavior, not just implementation steps.

A Good Split Is Deliberately Constrained

Good splits often come from choosing a useful constraint.

A team might start with one persona, one workflow path, one business rule, one data source, one product type, one platform, or one region.

These constraints keep the story small without turning it into a technical task.

The constraint should be intentional. “We’re supporting the happy path first” is a useful decision. “We forgot about the error cases” is not.

Done Does Not Always Mean Released

A story can be done without being released.

Done means the story is high quality; it is well tested; and what it does, it does well.

It does not always mean the resulting functionality is cohesive enough to release to customers.

Consider undo and redo. A team might complete undo in one sprint and redo in the next. When undo is finished, it works, it’s tested, and it behaves correctly.

But the product may feel incomplete without redo, so the team might choose to release both together.

That’s a release decision. It doesn’t change whether the first story was done.

Teams can handle this in different ways. They may use a feature flag, release to an internal audience, show the work in sprint review, or simply hold the completed functionality until related work is also done.

The right choice depends on the product.

The important point is that this is still a valid split. It creates value by producing a high-quality, tested piece of the larger capability, even if the team chooses not to deliver that value to users yet.

Use SPIDR To Find Better Splits

When a story feels too large, SPIDR gives teams five ways to look for smaller, valuable splits.

SPIDR stands for:

• Spike: Use a short investigation when uncertainty is preventing the team from knowing how to split the story.
• Paths: Split by alternate paths through a workflow.
• Interfaces: Split by user interface, platform, channel, or interaction mode.
• Data: Split by the type, amount, source, or complexity of the data involved.
• Rules: Split by business rules, validations, calculations, or exceptions.

The value of SPIDR is that it gives the team multiple ways to look at a large story. If one approach doesn’t reveal a good split, another often will.

An Example

Suppose a team is building software that recommends hotel room prices. The full story might require an algorithm that considers occupancy, day of the week, competitor prices, hotel ratings, historical demand, and other factors.

That’s too much for one sprint.

One split might start with a simpler version of the algorithm and the easiest data sources. The team might temporarily hold competitor price constant rather than build every integration or screen scraper immediately.

That first version would not produce a price a hotel manager should rely on. But it lets the team test part of the pricing logic while keeping a difficult variable stable.

Later stories can add competitor pricing, ratings, and other rules or data sources.

That’s a useful split because each step develops a working part of the larger capability. The team isn’t writing documents or building disconnected technical pieces. It’s making the product more complete in small, testable steps.

To go deeper into the five SPIDR techniques, read Five Simple But Powerful Ways To Split User Stories.

What To Do When A Story Seems Impossible To Split

Sooner or later, every team says, “This story can’t be split.”

Use a three-step response.

1. Try Harder

Most stories can be split.

Teams often stop too soon because they keep trying the same type of split. If every idea turns into frontend, backend, testing, or design tasks, try a different approach.

Look for paths, rules, interfaces, data differences, or learning opportunities.

A story that seems impossible to split today may look easy to split once the team has more practice.

2. Let It Take Two Sprints If Necessary

Don’t spend endless time forcing a bad split.

If the team truly can’t find a useful way to split the story, let it span two sprints.

That should be rare. But it’s better than creating artificial stories that add work or confuse the backlog.

3. Feel A Little Guilty

This is partly a joke, but only partly.

If a team lets one story take two sprints, they should feel just uncomfortable enough that it doesn’t become normal.

The point is not to shame the team. The point is to keep large stories from becoming an accepted habit.

Assume the story can be split. Use SPIDR. Ask for help. Try harder. Then, if needed, make a pragmatic decision and inspect what happened.

When Should Teams Split Stories?

Don’t split every story as soon as it enters the backlog.

If a team splits too far in advance, the backlog becomes harder to manage. Distant items multiply into many small stories. Some of that work will be wasted because the larger idea changes, moves down the backlog, or disappears completely.

A useful rule of thumb is to look about two sprints ahead. In practice, that may mean splitting items somewhere between one and a half and three sprints before the team expects to work on them.

That timing keeps near-term work small enough to finish without making the entire backlog too detailed too soon.

Story splitting often happens during Product Backlog Refinement, but it doesn’t have to happen only there. A Product Owner and one or two available team members may split a story before refinement. A team may discover during sprint planning that a story is too large and split it then.

Earlier is usually better. But late splitting is better than bringing an oversized story into the sprint unchanged.

Who Should Split User Stories?

Story splitting is not solely the Product Owner’s job.

A good Product Owner can often suggest useful splits. But many splits require technical insight.

Developers may know where the real complexity is, which parts are easy, which parts are risky, and which split will leave 95% of the work in one remaining story.

Story splitting should be collaborative.

Product Owners bring the outcome, priorities, user, and business perspective. Developers bring technical knowledge. Scrum Masters and agile coaches can help the team notice when stories are too large, when splits are task-based, or when refinement is getting stuck.

The best splits usually come from combining those perspectives.

Signs Your Team Has A Story Splitting Problem

Look for these symptoms:

• Stories regularly carry over from sprint to sprint.
• Work sits in progress for most of the sprint.
• Sprint reviews include only a few completed items.
• The board is full of backend, frontend, database, testing, or design backlog items.
• People say, “We can’t demo this yet.”
• Testing and integration pile up near the end of the sprint.
• Stories sound like projects: “Build reporting,” “Implement payments,” “Create onboarding.”
• Standups focus on tasks completed rather than outcomes finished.

Any one of these can happen occasionally. When they happen repeatedly, inspect story size and splitting.

For more on common problems, read Five Story-Splitting Mistakes And How To Stop Making Them.

Questions To Ask In Your Next Refinement Conversation

The next time a story feels too large, ask:

• What is the smallest outcome someone could use, learn from, or react to?
• Can we support one path through the workflow first?
• Can we defer an edge case or exception?
• Can we support one persona, product type, region, platform, or data source first?
• Are we splitting this into smaller stories or merely creating tasks?
• What must be true for this item to be considered complete?
• Would we be comfortable showing this as a completed change in sprint review?

These questions help the team look for smaller outcomes rather than smaller activities.

Learn To Split Stories Faster

Refinement meetings become painful when teams don’t have a repeatable way to split large stories into smaller, valuable ones.

Teams spend too long debating a story, only to end up with something still too big for the sprint. Or they split the story into technical tasks and discover later that nothing is truly done.

In Better User Stories, you’ll learn practical ways to write, split, and refine user stories so your team can spend less time arguing about the backlog and more time finishing valuable work.

Story splitting is a skill. Once a team develops it, refinement gets faster, sprint planning gets easier, and more work reaches done.

Last update: May 13th, 2026