26 story slicing techniques for any scrum team

www.agilebin.com
26 Story Slicing Techniques for
Any Scrum Team
Version 0.3
May 2020
Vijay Kulkarni
www.agilebin.com 1

Agenda
• Why a story needs to be sliced?
• Incremental Delivery
• Identify valuable shippable units (VSUs)
• Story slicing techniques
• Story Naming Convention
• Story slicing mistakes
www.agilebin.com 2

Credits
References
• http://agileforall.com/patterns-for-splitting-user-stories/
• https://blog.agilistic.nl/8-useful-strategies-for-splitting-large-user-stories-and-
a-cheatsheet/
• https://blogs.itemis.com/en/spidr-five-simple-techniques-for-a-perfectly-
split-user-story
• https://xp123.com/articles/twenty-ways-to-split-stories/
• https://www.mountaingoatsoftware.com/blog/five-story-splitting-mistakes-
and-how-to-stop-making-them
www.agilebin.com 3

Why a story needs to be sliced?
In enterprise environment,
where software's grows
from simple multi layer 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.
www.agilebin.com 4

INVEST
• I - Independent
• N - Negotiable
• V - Valuable
• E - Estimable
• S - Small to fit
• T - Testable
www.agilebin.com 5

Incremental Delivery
www.agilebin.com 6

Incremental Delivery
www.agilebin.com 7

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.
www.agilebin.com 8

Client – PO conversation
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.
www.agilebin.com 9

Story Value
• 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.
www.agilebin.com 10

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.
www.agilebin.com 11

ETL : VSUs
• Minimum deployable units with business value are
• New workflow
• Updates to existing workflow
• Update existing workflow related steps (like Unix script etc.)
• One time data load activities
www.agilebin.com 12

DAL : VSUs
• New DAL service development
• Update to existing DAL service
• New lookup code additions
• Database extract services
• Initial or delta batch Load Services
• Change notification to third party
www.agilebin.com 13

Micro services : VSUs
• Service methods
• PUT
• GET
• DELETE
• POST
www.agilebin.com 14

Database : VSUs
• Create new database object
• E.g. Create table etc.
• Update existing database object
• E.g. Update script etc.
www.agilebin.com 15

Product Anatomy
Product
Features
Features
Components
Sub Components
……
……
Customer
Components
Sub
Compon
ents
…
…
…
…
www.agilebin.com 16

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
www.agilebin.com 17

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
Horizontal
Vertical
Context
www.agilebin.com 18

Story slicing techniques
www.agilebin.com 19

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
Ingredient 1 : Patterns
Ingredient 2 : Ideas
Ingredient 3: etc. etc.
www.agilebin.com 20

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.
Epic
Story
Story
Story
www.agilebin.com 21

Business Rules
Identify business rules. Identify areas where change in constant. Split
stories across business rules. Go for the default implementation first
and then add business rules incrementally.
Default Implementation
Business rule 1 : Discount
Business Rule 2: Age limit
Business Rule 3: xyz
Business Rule 3: pqr
Default Implementation
Business rule 1 : Discount
Business Rule 2: Age limit
Business Rule 3: xyz
Business Rule 4: pqr
www.agilebin.com 22

Workflows
Identify workflows in the process. If there are multiple workflows, the
split the stories at workflow level and try to further split the complex
workflow into simpler workflow and add incremental steps. Path.
Step 1 Step 2
Step 3a
Step 3b
Step 4a
Step 4b
www.agilebin.com 23

Interface Methods
Split across interface methods. Useful at API layer.
Interface
GET
PUT
DELETE
GET
PUT
DELETE
www.agilebin.com 24

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.
Credit Card Process for
Visa
MasterCard
Diners Club
American Express
Discover
Credit Card Process for Visa
MasterCard
Diners Club
American Express
Discover
www.agilebin.com 25

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.
Complex process performing 20 things
at once.
Add complexity
Simple
implementation
Minimum
required version
www.agilebin.com 26

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.
Do this and that
Do this
Do that
www.agilebin.com 27

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.
Process for all members
Process for residents
Process for migrants
www.agilebin.com 28

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.
Data entry form with
data viewing grid Data entry form Data viewing grid
Data entry form with
data viewing grid
www.agilebin.com 29

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.
Login page which load in 2 seconds and
even works without mouse
Login page
Optimization of login page load time
Make it work without mouse
www.agilebin.com 30

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!
Large scale
Small scale
Large scale
www.agilebin.com 31

Operations
Multiple operations can be hidden under the ‘manage’ word.
As a user, I can manage my account
I can sign up for an account.
I can edit my account settings.
I can cancel my account.
Update profile picture
Update personal information
www.agilebin.com 32

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?)
Make this happen
Make sure this do not happen
Make this happen
Make sure this do not happen
www.agilebin.com 33

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.
Desktop
Tablets
Mobile
Internet Explorer
Google Chrome
www.agilebin.com 34

User Roles
Split by user roles.
User logs in
Admin logs in
Member logs in
www.agilebin.com 35

External Dependencies
External dependencies can be divided and served one at a time. These
dependencies can be downstream or upstream dependencies.
This change must support all five
external teams in one go
Support Team A
Support Team B
Support Team C
Support Team D
Support Team E
www.agilebin.com 36

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 and Development
Research
Development
www.agilebin.com 37

Manual first then Automate
Sometime developing fully automated solution is relatively big work as
compared to developing manual version of it. In some situation it make
sense to develop manual version first then automate it.
Fully automated solution
Develop manual solution
Automate the manual solution
www.agilebin.com 38

Batch Vs. Online
A batch system doesn't have to interact directly with the user.
Front end solution
+
Backend processing
Front end solution
Backend processing
www.agilebin.com 39

API only Vs. User Interface
Start with API only version and add user interface later.
Complete system with User Interface
API
User Interface
www.agilebin.com 40

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.
Support multiple users simultaneously
Single user version
Make it multiuser
www.agilebin.com 41

Character UI or Script UI Vs. GUI
Start with basic command line interface first and build fancy graphical
user interface separately.
> Input a
>5
> Input b
>5
> 10
Calculate
A
B
www.agilebin.com 42

Parts Vs. Assembly
Sometimes the shippable valuable unit is large enough to not to fit in a sprint
and can not be sliced further keeping the value intact. In such situation, parts
of the unit can developed separately and then assembled. Integration testing
to be done after the assembly.
www.agilebin.com 43

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.
POC
Prepare Environment
Develop base framework
Implementation
POC : Spike
Prepare Environment : Spike
Develop base framework: Spike
Implementation : Story
www.agilebin.com 44

Enabler Vs. Implementation
Sometime 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.
As a user, I can pay by credit card
Implement credit card processing
Prepare project repository: Enabler
Get architectural guidance: Enabler
Get the UI design ready from artiest:
Enaber
www.agilebin.com 45

Story Naming Convention
• If the stories are going to be sliced left & right then story naming convention become utterly
important.
• Recommend Story Naming Conventions
• A common challenge for teams is how to manage work in the backlog that doesn't fit the “As a <type of user>,
I want <some goal> so that <some reason>” template. Feature-Driven Development (FDD and not directly
related to TDD or BDD) is a minor player in the Agile methodology space. It does have a nice format for
expressing Microservices.
• In FDD (not directly related to TDD or BDD), a feature is written in this format: <action> the <result>
<by|for|of|to> <object>
• As examples, consider these:
• Pay a Claim
• Register a Customer
• Generate a unique identifier for a transaction
• Change the text displayed on a kiosk
• Merge the data for duplicate transactions
• In each case, the feature description starts with the action (a verb) and ends with what would be
an object within the system. Author Mike Cohen has written an article expanding the discussion
on development other than stories that live in the backlog.
www.agilebin.com 46

Story slicing mistakes
• Treating Story slicing as Just the Job of the Product Owner
• slicing Stories along Technical Boundaries
• 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
www.agilebin.com 47

You Have Done It!
• You are now powered with tools and technique to better story slicing
• Congratulations
• Please share your feedback at www.agilebin.com
• And yes, don’t forget to try the free story pointing tool – agilebin poker – at
www.agilebin.com/poker
• Thank you.
www.agilebin.com 48

26 story slicing techniques for any scrum team

Recommended

More Related Content

What's hot (20)

Similar to 26 story slicing techniques for any scrum team (20)

Recently uploaded (20)

26 story slicing techniques for any scrum team