25 Story Slicing & Splitting Techniques That Every Scrum Team Must Know

In this article we will discuss 25 story slicing & splitting techniques that every scrum team must know. During story refinemnt meeting, it is critical to slice the stories, small enough, to fit into the sprint.

Why a story needs to be sliced?

In enterprise environment, where software's grows from simple to complex multi tier systems, carving out valuable product increment to be delivered in a sprint become more and more critical.

Getting scrum teams to a common understanding on how to slice valuable stories becomes essential.

Complex multi-tire systems

Following are the reasons to slice a story

  • Create valueable and meaningful stories
  • Create stroies small enough to fit into the sprint
  • Stories can be production ready at the end of the sprint
  • Stories small enough so that the developement and testing can be fit into one sprint
  • Incremental Delivery
  • Sprint feedback loop
  • Story must satisfy INVEST criterion
    • I - Independent
    • N - Negotiable
    • V - Valuable
    • E - Estimable
    • S - Small to fit
    • T - Testable 

Incremental Delivery

Incremental Delivery is key principal of agile. The end user should receive the working software incrementaly at the end of every sprint. Following images show how the incremental delivery looks like.

Incremental Delivery


Incremental Delivery

Agile Workflow Vs. Non Agile Workflow

How will you build a space shuttle using scrum framework?

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is a process framework that has been used to manage work on complex products since the early 1990s.

Everyone will agree that a space shuttle is complex product.

Then the question:

How will you build a space shuttle using scrum framework?

In this build space shuttle example, for client, the entire value boils down to that one switch, which he would press to fire up the space shuttle.

Space Shuttle

Client – PO conversation for buidling Space Shuttle

Client: Can you guys build a space shuttle for me. It will be first of its kind that nobody has build before.

PO: Sure. We can build this product using scrum and deliver it incrementally sprint by sprint.

Client: I want the complete product, individual parts are of no use to me. Space shuttle will be launched only when it is fully ready.

PO: We will be building the product component by component. Each component will add value to the product. We want your feedback as we build these components, to make sure that we are on right track. We want you to participate in the whole process.

Client: Sounds great. In this way, I can allocate budget for each iteration and see the value being delivered at the end of iteration.

PO: That's right. I will create the product backlog. The most critical component guess-o-meter will be at the top priority.

After first sprint...

PO: Team has built the guess-o-meter and tested it successfully. Lets see the demo.

Client: I am impressed. Looks like we need to add more power to this guess-o-meter as I am expecting heavy payload on this space shuttle.

PO: Sure. Let me add that requirement to the product backlog and prioritize it.

After few more sprint....

Client: The space shuttle is really coming along very good. At the beginning, I was not very clear on what I wanted you to build. But with incremental value delivery the product is took shape piece by piece.


Story Value

There are two level of values

  • Value to business or end user
  • Value to product itself

Every increment may not add value to the business or end user but it may add value to the product itself. 

Every product increment may not be released to customer at the end of the sprint, but it should add value to the product. 

The battery or oil filters inside the car is not directly used by the car driver but they are necessary units for the functioning of the car.

Identify valuable shippable units (VSU)

VSUs are the minimum shippable unit which also valuable to the product

For consumers, the end product feature is the entire API service but from release point of potential VSU can be a service method.

Multiple VSU may required to complete the end product feature.

Each VSU can be considered unit of delivery of value and can form a Story.

VSUs may not always cut across technical boundaries. In larger system technical boundaries may define components.

Horizontal Vs Vertical Slicing

Product Anatomy: products are complex and layerd.

Product Anatomy

Aggregation Vs Composition

Composition is “Made up of” relationship

  • Engine is made up of various parts.
  • Strong relationship

Aggregation is “Is Part of” relationship

  • Battery is part of the car
  • Weak relationship

In aggregation, sometime, each part is a product in itself

  • E.g. Battery of car is a product in itself

Automobile Anatomy


Horizontal Vs Vertical

Horizontal Slicing Vs. Vertical Slciing

Horizontal or vertical discussion has third dimension “Context”

Determine the value that is being increment to the product

Try not to slice that value in horizontal

Story slicing techniques

Recipe Vs. Ingredient

In these story slicing technique do not look for recipe for slicing the stories but look for ingredients that will help you to cook multiple story dishes.

Recipe Vs. Ingredient

First look at Epic : Best Practice

Product owner to discuss the epic with development team before even try to take first stab at creating any stories.

During the discussion possible stories will be identified.

This will become input to product owner to create further stories.

First Look at the Epic

Business Rules

Determine the business rules. Identify areas of constant change. Divide stories according to business rules. Start with the default implementation and then gradually add business rules.


Business Rules


Identify workflows throughout the process. If there are multiple workflows, divide the stories at the work flow level and try to further divide the complex workflow into simpler workflows with incremental steps.


Interface Methods

Split across interface methods. Useful at API layer.

Interface Methods

Repeat Effort / 1 Vs. Many / Base case Vs. General case

First implementation takes time but then it can be reused repeatedly for rest of the implementation. Separating stories for the core logic with add-ons. 

It's usually easiest to get one right and then move to a collection.

Repeat Efforts

Split simple from complex

Extract the core simple and minimum implementation from the complex (all at once) scenario. Go for simple implementation first and then build the complex implementation around that.

Split Simple from Complex

Split condition Vs. Full condition

Treat "and," "or," and "then" and other connector words as opportunities to split. Simplify a condition, or do only one part of a multi-step sequence.

Split Condition

Split across Data Sets

If multiple complex data sets are involved in process then split across data sets by category. If implementation is similar for multiple categories then use repeat efforts technique.

Split Across Data Sets

Split and then combine

Split the process or (user interface) into multiple parts and then combine at the end. Sometimes the individual parts may not provide business values but they can be valid product increments.

Split and then combine

Non functional requirements - Less "ilities," Vs. More "ilities"

Non functional and usability requirements can be separated in to stories from the functional implementation.

It's easier to defer non-functional requirements. (A common strategy is to set up spikes as side projects to prove out architectural strategies.)

Cross cutting aspects can be separated at architecture design level. 

Non functional Requirements

Small scale Vs. Large scale

A system that works for a few people for moderate data sets is a given. After that, each step is a new story. Don't forget the load tests!

Small Scale Vs Large Scale


Multiple operations can be hidden under the ‘manage’ word. 


Happy Path Vs. Unhappy Path  - Main flow Vs. Alternate flows

Separating the happy path implementation from the unhappy path or negative conditions can help. slicing  the positive test conditions and negative test conditions can help. (If you can't complete the most trivial transaction, who cares that you have great recovery if step 3 goes bad?)

Happy Path

Split by platform and devices (UI)

Split by platform like Apple, android, windows, web and devices like desktops, tablets, mobile phones or touchscreens can help. Slicing by browser categories also helpful sometimes.

Platform and Devices


User Roles

Split by user roles.

User Roles

External Dependencies

External dependencies can be divided and served one at a time. These dependencies can be downstream or upstream dependencies.

External Dependencies

Research Vs. Development

Sometimes the ‘How’ part is not so clear to the scrum team to start the development. Research needs to be done before the development can be started. In this situation, it is worthwhile to separate the development from the research. Be aware of who should do the research – product team or development team.

Research Vs Development

Manual first then Automate

Sometimes developing fully automated solution is relatively big as compated to developing manual version of it. In some situation it make sense to develop manual version first then automate it.

Manual first then automate

Batch Vs. Online

A batch system doesn't have to interact directly with the user.

Batch Vs Online

API only Vs. User Interface

Start with API only version and add user interface later.

API only vs User Interface

Single-User Vs. Multi-User

While developing for multiple users you may run into issues like  "what happens when two users try to do the same thing at the same time." Focus on single user version first and create separate stories for multiuser scenarios.

Single User Vs Multi User

Character UI or Script UI Vs. GUI

Start with basic command line interface first and build fancy graphical user interface separately.

Character UI or Script UI Vs GUI

Parts Vs. Assembly

Sometimes the shippable useful unit is too large to fit in a sprint and cannot be sliced further without losing value. In this case the unit's components can be developed separately and then assembled. After assembly, integration testing will be performed.

Parts Vs Assembly

Spike Vs. Implementation

Is it good idea to create spike task in following situations. Spike can be technical work not related to specific story.

Need for proof of concept (POC) before the development can be started

Prepare development environment 

Develop technical framework, base libraries etc.

Spike Vs Implementation

Enabler Vs. Implementation

Sometimes there is not enough understanding for the work to be done. Or there are some pre requisites to start the work. In such care creating enabler task can help. Enabler task should enable make the specific story small enough to fit.


Enabler Vs Implementation

Story slicing mistakes

  • Treating story slicing as just the Job of the product owner.
  • Slicing stories along technical boundries.
  • Specifying the Solution as part of the story.
  • Using a spike/enabler on every story.
  • Thinking all business rules need to be enforced from the start.


Fiviza LLC
6010 W Spring Creek Pkwy Suite 362, Plano, TX 75024

Agilebin is the product of Fiviza LLC.

Follow Us