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

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.

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.

 

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.

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.

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

 

Horizontal Vs Vertical

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.

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.

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.

 

Workflows

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.

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.

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 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 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 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.

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. 

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!

Operations

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?)

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.

 

User Roles

Split by user roles.

External Dependencies

External dependencies can be divided and served one at a time. These dependencies can be downstream or upstream 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.

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.

Batch Vs. Online

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

API only Vs. User Interface

Start with API only version and add user interface later.

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.

Character UI or Script UI Vs. GUI

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

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.

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.

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.

 

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.