Isi presensi dulu yaaa...

bit.ly/kelasBhari3
#SplittingStory

Splitting Story

A guide on how to split user story...

Agile Coach, 2019

Bukalapak
#SplittingStory

01. The Problem

02. The Why(s)

03. Splitting Story Concept

● Issue Type Definition
● Initiative to Epic
● Epic to Story
● Story to Subtask
Bukalapak
#SplittingStory

The Problem
Bukalapak

What is the problem...

#SplittingStory

Some problems that occur...

1. Too long on state “inprogress” and invisible detail progress

a. When a story is big and especially when there’s no detail (sub-task), the
development can be unseen and it gives “no progress” impression.
b. Less transparency of the details and progress.
c. Gives bad impression that the engineer is underutilized even though they has
worked hard
2. Many stories carried-over across sprint
a. It happens when a story is too big to be done in 1 sprint which can be avoided
by slicing the story into smaller stories.
b. It happens also when the team is bad at planning and estimation.
3. Dependencies with other teams can be impediments or blocker to the team.
a. If the story is too big, sometimes the dependencies with other teams are
unseen.
Bukalapak

b. Unseen dependencies makes the story can be dragged for a long time.
#SplittingStory

The Why(s)
Bukalapak

Why do we need to split the story...

#SplittingStory
WHY do we need to split
stories?
Because, when we split stories....
(1) Teams would be able to deliver
stories that are valuable for user
(more) frequently.
(2) The scope for each story would
be clearer, which provides better
transparency for team members
and stakeholders.
Bukalapak
WHY do we need a
guideline to split stories?
So that we are on the same page
together! The development team,
the product management team,
the product design team, and other
stakeholders involved. Moreover,
this is in line with our development
& deployment rules.
#SplittingStory

Splitting Story Concept

Bukalapak

What concepts are there in splitting stories...

#SplittingStory

1. Issue Type Definition

INITIATIVE Issue Type Structure

EPIC

STORY EMERGENCY BUG

SUB-TASK
Bukalapak

Source: Atlassian | Agile Glossary | Scrum Alliance

#SplittingStory

1. Issue Type Definition

INITIATIVE is collections of epics that drive toward a common goal. This is not one
of the issue types in JIRA.

EPIC is body of work that can be broken down into specific tasks (called “stories,” or
“user stories”) based on the needs/requests of customers or end users

STORY is self-contained unit of work agreed upon by the developers and the
stakeholders. Stories are the heart of Scrum, and the building blocks of your sprint.
It’s an end goal, not a feature, expressed from the software user’s perspective. The
purpose of a user story is articulate how a piece of work will deliver a particular
value back to the customer.
Bukalapak

Source: Atlassian | Agile Glossary | Scrum Alliance

#SplittingStory

1. Issue Type Definition

BUG is customized issue type, a problem which impairs or prevents the functions of
the product

EMERGENCY is customized issue type, extremely severe issues that necessitate one
or multiple teams to drop what they are doing and fix the issue ASAP

SUB-TASK is the smallest part of a story, usually used to breakdown technical needs
or any activity that supports the completion of the parent issue. It can be a "child" of
any issue type.
Bukalapak

Source: Atlassian | Agile Glossary | Scrum Alliance

#SplittingStory

2. Initiative to Epic

Some methods below that can be used to split initiative into epic. You can hover and click on text for
the details.

M
E
T
H Split based on Menu Using Story Map
source: Medium
O
D
S
Bukalapak
#SplittingStory

2. Initiative to Epic : Do’s

What you have to do when you split initiative into epic.

1. Create epics in JIRA based on product roadmap in the beginning of each quarter. You can
create the story later.
2. Team should be aware of the epics schedule in the product roadmap
Bukalapak
#SplittingStory

2. Initiative to Epic : Don’ts

What you shouldn't do when you split initiative into epic.

1. Avoid epics that don't have estimated time of delivery

2. Avoid epics that takes longer than 2 quarters, re-analyze whether the epic can be split into
smaller epics
Bukalapak
#SplittingStory

3. Epic to Story/Bigger Story to Smaller Stories

Some methods below that can be used to break down epic into story. You can hover and click on text
for the details.

M S.P.I.D.R
Source: Mountain Goat Software
E
T
H
O
D Prepare, Apply,
10 Strategies
S Source: Medium Evaluate
Source: Agile for All
Bukalapak
#SplittingStory

3. Epic to Story : Do’s

Some points below that you have to do when split epic into story.

1. Fit in 1 sprint (2 weeks)

2. “Done” status in JIRA for each story on MWEB/DWEB platform is Deployed
3. “Done” status in JIRA for each Android/iOS stories to Merged to Branch, but create another
story to track the regression & release process.
4. Story automation (SDET) can be created in parallel with the testing scenario
5. A story should be testable.
6. Whenever possible, split the stories from user perspective to avoid the “heavy testing in the
end of the development of an epic”. When the testing still needs to be combined in order to not
“repeat” the testing for the same flow, it’s OK.
7. Prioritize your story with Low, Medium, High, Critical. If any emergency, you can use issue type
Emergency
8. Set your own "splitting" threshold: when your story point exceed that number, you have to
split the story.
Bukalapak
#SplittingStory

3. Epic to Story : Do’s

11. Split stories of Mixed Priority

Separate a large story into smaller stories if the smaller stories have different priorities.
For example initial story : “As a user, I am required to login to the system”
Split stories per iteration:
● “As a user, I can login to the system using the valid username and password”
● “As a user, I can’t access the system using the invalid password three times in a row”
● “As a user, I am sent an email stating that an attempt was made to use my account if I am
denied access”
12. If you want to combine multiple tiny stories
For teams working in two-week iteration, splitting features such that each can be done in two
to five days or so is appropriate. (please still use story points! You should know approximately
how to equate this to 2-5 days). Do combine multiple tiny stories. The combines stories are
estimated as a whole rather than individually. Combine related stories so that prioritizing
them is easier
Bukalapak
#SplittingStory

3. Epic to Story : Don’ts

Some of the points below that you shouldn't do when split epic into story.

1. Split story into task

For example, do not split a story into the following:
● Code the user interface
● Write the middle tier
● Configure database

2. Avoid the temptation of related changes

Avoid making things worse by adding work to the story! Do not add changes to an
appropriately sized feature unless the related changes are of equivalent priority.
For example, do not do this:
● “While I’m in that code, I might as well take care of these other lingering changes”
● “Oh, the scope becomes bigger due to stakeholder request… Let’s just add it to this story,
I don’t wanna create another story”
Bukalapak
#SplittingStory

4. Story to Subtask

Some methods below that can be used to break down story into subtask. You can hover and click on
text for the details.

M
E
T
H The Wisdom Split based on Unit Role
Source: Medium
O
D
S
Bukalapak
#SplittingStory

4. Story to Subtask : Do’s

Some points below that you have to do when split story into subtask.

1. Creating Subtask
● Subtask should be idea of engineer as technical expertise
● Before or at scrum event marketplace, it can help to estimate story point
2. Subtask Assignee
● Each subtask has 1 assignee
● If subtask has more than 1 assignee, then choose one as main pic who ensure it done
3. Differences between Story and Subtask Assignee
● If 1 story has many subtask, then choose one assignee as main pic who ensure the story
done (deployed/merged)
4. If there are more than 15 subtasks in 1 story, consider whether it can be split into a new story
Bukalapak
#SplittingStory

4. Story to Subtask : Don’ts

Some of the points below that you shouldn't do when split an story into subtask.

1. Give the story points on issue type subtask

Bukalapak
Spike
It’s time
for
Workshop!
23
Rules and Assumptions
1. Split the story on JIRA board into smaller ones using one (or more) of the
method shared above. Remember, create the story based on user’s
perspective.
2. Each story must have subtask(s)
3. No need to set the priority for every story
4. At the end, number of stories on your backlog cannot be more than 5
5. Sprint duration is two weeks
6. The product will be developed on 3 platforms: Desktop web, iOS, Android

bit.ly/BootcampJKTQ319JIRA
#SplittingStory

bit.ly/BootcampJKTQ319JIRA
Bukalapak
#SplittingStory

Detail of Splitting Method

Bukalapak

Detail of mentioned splitting method on section “Splitting Story Concept”...

#SplittingStory

2. Initiative to Epic: Split based on Menu

1. Gather of all the menus in your product, both existing and future ones
2. Choose which menus will be developed in a particular planning period
(eg: Product Roadmap Quarterly)
3. Write a brief description of the scope to be developed in each menu
4. Each menu in point 2 illustrates the epic, with a title that can be taken from point 3
Bukalapak

back
#SplittingStory

2. Initiative to Epic: Using Story Map

1. Gathering the MAJOR user journey or user tasks (The things People do)
2. Group the user task
Move things that are similar to each other closer to each other and things that are
dissimilar to each other should be moved farther apart.
3. Name each group
4. Each group represent epic

for example: User Story Mapping squad WOW

Bukalapak

back

Source: User Story Map

#SplittingStory

3. Epic to Story: S.P.I.D.R

● In this section using SPIDR approach from

Mountain Goat Software, Just to recap, SPIDR
stands for:
● Spike - A research activity can give you the
knowledge you need to split a complex story.
● Paths - If a user can do something in multiple
ways, that’s a great area for splitting.
● Interfaces - Splitting your story by browser, or
hardware, or deliver a complex interface in
iterations.
● Data - You may be able to deliver value in an
iteration by focusing on one type of data.
● Rules - Relaxing support for the rules in an
iteration can make large stories smaller.
Bukalapak
 Example:
<think of something that is complex and large, which
your engineers can’t even estimate>
[SPIDR]
Find out whether you can do a small research activity
Spikes that would help you either:
Make a large story smaller - Make the other stories of a manageable size
by pulling out a spike, - See ways to split the story easier (from the new
which is a research activity
knowledge, the result of the spike)
after which the team will
know more.
 Draw a simple flowchart of what happens in a story. Each
sequence of steps/possible alternative paths can be a
story. Expand one big step of the flowchart into a story.

[SPIDR] Initial story: “As a user, I can pay for purchases (in an
Paths online store)”

Consider the paths Split stories:

through a story and split - “As a user, I can pay with a credit card”
each path into its own
- “As a user, I can pay with PayPal”
story.
- “As a user, I can pay with BukaDompet”
 Split out stories by browser type or version, or by
[SPIDR] different hardware. Consider building a minimal user
Interfaces interface first or leave styling out of an interface initially.

Split a story across [you’re familiar with this already]

multiple interfaces if
supporting those
interfaces makes the story
take significantly longer to
develop.
 Can a first story support valid data and a later story add support
for invalid data? How about frequent types of data and less
frequently seen types of data?

Epic: “As a user, I can enter my balance sheet information”

Stories:
1. “As a user, I can enter summary balance sheet data”
[SPIDR] 2. “As a user, I can enter categorized balance sheet data”
3. “As a user, I want the values I enter to be validated so that I
Data don’t make any mistakes”
4. “As a user, I can enter detailed loan information”
Look for ways to split the
- “As a user, I can enter detailed information about my
story based on the type of
real estate holdings”
data that must be
supported. - “As a user, I can enter detailed information about my
cash holdings, including checking and savings
accounts”
 Consider removing cross-cutting concerns (such as security,
logging, error handling, and so on) and creating two versions of
the story. Or, consider splitting a large story by separating
functional & non-functional aspects into separate stories.

Initial story: “As a user, I am required to log in with a

[SPIDR] username and password before using the system.”

Rules Split stories:

1. Login without any security precaution
Split based on business rules,
2. Login with a certain rule on password length & special
technology standards, or such
characters
that must be supported.
3. Login with encrypted password when transmitted and
Consider relaxing support for stored
these rules in an initial story. 4. ...
Add support for additional
back
rules in subsequent stories.
#SplittingStory

3. Epic to Story: Prepare, Apply, Evaluate

In this section,
sourced from
Agile for All
Bukalapak
#SplittingStory

3. Epic to Story: Prepare, Apply, Evaluate

● Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable,
Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories.
But the stories after splitting still have to follow the model.
● This approach contain 9 patterns:
1. Pattern #1: Workflow Steps
2. Pattern #2: Business Rule Variations
3. Pattern #3: Major Effort
4. Pattern #4: Simple/Complex
5. Pattern #5: Variations in Data
6. Pattern #6: Data Entry Methods
7. Pattern #7: Defer Performance
8. Pattern #8: Operations (e.g. CRUD)
9. Pattern #9: Break Out a Spike
Bukalapak

● See the Story Splitting Cheat Sheet back

#SplittingStory

3. Epic to Story: 10 strategies

● In this section, sourced from Medium

● This approach contain 10 strategies:
Strategy 1: Breaking down by workflow steps
Strategy 2: Breaking down by business rules
Strategy 3: Breaking down by happy / unhappy flow
Strategy 4: Breaking down by input options / platform
Strategy 5: Breaking down by data types or parameters
Strategy 6: Breaking down by operations
Strategy 7: Breaking down by test scenarios / test case
Strategy 8: Breaking down by roles
Strategy 9: Breaking down by ‘optimize now’ vs ‘optimize later’
Strategy 10: Breaking down by browser compatibility
● See Breaking down Product Backlog Items, a cheatsheet
Bukalapak

back
#SplittingStory

4. Story to Subtask: The Wisdom

● In this section, sourced from Medium

● This approach is explained using code review process as case study on product development.
The goal is reduce code review time without decreasing the quality of code.
● Let’s try to formalize things. What is a “Code Review”? It’s the process of reading code by other
developers and giving feedback to the author, ensuring that code’s implementation brings
business value and don’t break existing functionality. So, there are 3 things to consider:
reading, giving feedback, providing business value. Knowing this now, lets identify the qualities
of an effective merge request:
○ Business orientation
○ Isolate risks
○ Single purpose
● You can read the details and follow the flow of the article
Bukalapak

back
#SplittingStory

4. Story to Subtask: Split based on Unit Role

● Gather all roles that can develop the user story

● Define task for each role as a subtask
● Each role can be assigned to more than 1 subtask
● For example from squad NOOB:
User Story:
“Users can unclaim the email verification so they won't get transaction message from unknown
users”
Subtask:
[FE] Unregistered users, unclaim successful! page
[FE] Registered users, wrong account! page
[BE] Unclaim function
Bukalapak

back
#SplittingStory

Thank You

...

Agile Coach, 2019

Bukalapak