Db workshop - art of story splitting and writting

Workshop
Slicing and Splitting
Stories
The art of slicing and splitting Stories and deliver
value every sprint
Phil van Dulm

Main Audience
Product owners & Business Analists
 Basic knoledge of agile/scrum
 Experience with writing user stories
 Help the development team to
understand your needs!
Development team
 knoledge of agile/scrum
 Help the Product Owner to get value as
soon as possible!
2

goals
After this workshop:
- You write excellent user stories / PBI
- You apply acceptance criteria perfectly
- You apply Definition of Ready perfectly
- You apply Definition of Done perfectly
- You understand vertical slicing
- You know how to split stories
3

Index
1. Product owner
2. Product Statement & core Values
3. Persona’s and Actors
4. Core activities Persona’s Actors
5. Story Telling & Walking Skeleton
6. MVP and Release management
7. Product Backlog items
8. User stories & Acceptance Criteria
9. Vertical Slicing & Splitting
10. Tools, Links, Concerns and end note
4

How project variables are set
5

6
Always
7%
Often
13%
Some-
times
16%
Rarely
19%
Never
45%
…a waste of
money!
… probably a
waste of money!
…Value for money!

The backlog will be like…
11

Product Statement and
Core Values.
13

Product Statement & Core Values
Company Statement & Values
Goals
Target
audience
Product Statement
Core
Values
Persona’s
actors
Core Activities
User Story User Story
14

A Product needs to have a main goal
and purpose. Define this statement and
the core values.
This helps you to make decisions
based on Value during development…
It also prevents feature Creep!
15

Example 1: Online Retailer:
“We intend to provide our customers
with the best online shopping
experience from beginning to end, with
a smart, searchable website, easy-to-
follow instructions, clear and secure
payment methods, and fast, quality
delivery.”
16

Example 2: Blizzard Entertainment:
“DEDICATED to creating the most epic
entertainment experience EVER”
17

ADP | Product Owner Training |
18

Eight core values
1. Gameplay FIRST
2. Commit tot QUALITY
3. Play nice; PLAY FAIR
4. Embrace your INNER GEEK
5. Every voice MATTERS
6. Think GLOBALLY
7. Lead RESPONSIBLY
8. Learn & GROW
http://us.blizzard.com/en-us/company/about/mission.html
ADP | Product Owner Training |
19

Example: Credit Card company
“ we want to give our costumer a mobile
application that provides real time
information about his account and gives a
secure, second authentication method for
online purchases”
Core Values:
1. Secure & Save
2. Fast & Simple
3. Real time
20

21
Core Values Deutsche Bank (Spain?)

Assignment 30 min:
1. Make/Review a/your Product Statement*
2. (Re)write your top 5 Core values +
description**
* Try to related with corporate statement mission
** Tyr to related with corporate goals values
22

Know your users, actors,
and stakeholders.
23

Users, Persona’s, Actors and Stakeholders
24

Users, Persona’s, Actors and Stakeholders
Assignment 30 min:
Write down:
- target users/persona’s + small description
- all actors for your product
- (service-desk, security officer, release
manager, product owner, product specialist,
marketing)
- Important stakeholders
25

Core activities of the users
and actors
26

Product Owner Assignment
Assignment 45 min:
New Product or Existing
- Make a list of activities that your users have to
perform to gain the need they have.
- Be open minded, it’s brainstorm time 
- One activity per post-it
- Do the same with the actors of your product, which
activities do the need to perform to help the users
achieve their goals
27

Story Telling
Once up a time….
1. It’s Tuesday morning, and Mary is working on her
computer. She wants to book Training on a public Certified
Scrum Product Owner course taught by Thomas.
2. Mary visits site and chooses a public CSPO class.
3. She enters the participant information including first name,
last name, email address, special dietary requirements.
4. She then chooses a payment option and enters the
payment details.
5. Mary accepts the terms and conditions, and confirms the
booking.
6. Mary sees that her booking has been successful. After a
short while,
7. Roger receives an email confirmation with the booking
details.
29

Story Telling & Walking Skeleton
32
time
Actors/Persona’s & Core Activities
Actor 1
activity
Actor 1
activity
Actor 2
activity

Story Telling and Walking Skeleton
33
Sequential in Time
Actor 1
activity 1
Task /
user story
sub-tasks
Actor 1
activity 2
Actor 2
activity
Task /
user story
Task /
User story
Task details
Necessity
Less
optional
More
optional

35
Credit card
owner /
checking
transactions
Listing all
transactions
last month
Credit Card
owner /
checking
credit
show
transaction
details
Show
remaining
credit
Example Credit Card
Show
reservations
Choose month
and show
transactions
Listing all
transactions
last month
Show total
spend
Explain: Why is
this important!
What is the need
of the costumer?
Sequential in Time
Necessit
y
Explain: Why is
this important!?
What is the need
of the costumer?

36
Credit card
owner /
checking
transactions
Listing all
transactions
last month
Credit Card
owner /
checking
credit
show
transaction
details
Show
remaining
credit
Example Credit Card
Show
reservations
Choose month
and show
transactions
Listing all
transactions
last month
Show total
spend
Sequential in Time
Necessit
y

37
The backbone
 Actors / persona’s
 Core activities
 Epics / Themes
The walking skeleton
 user stories
Great for
 Big picture & overall product
 Product owner / Stakeholders
 Focus and minimal viable product
 Release planning
http://www.agileproductdesign.com/
More flesh Release 1 / MVP

Organize & Managing
Releases and
Minimal Viable Product
38

42
Story map (Business Prio) After a couple of sprints
Continues attention for change and priority
At the end of the project
End to end business
process
Necessity
R1
R2 R3

Story Telling & Walking Skeleton
Assignment 45 min:
New Product or Existing
- Restructure all actors, activities and sub-task/stories
and put them in a Walking Skeleton
- Determine your MVP and releases
43

A Product Backlog Item (PBI)
A Product Backlog Item represents a
small piece of business value that a team
can deliver in one iteration.
Business Value:
 Increasing user/actor satisfaction
 Increasing quality (performance / stability)
 Increasing knowledge for team / PO
 Decrease operational cost
45

Valid Product Backlog Items
46
Features
Definition
Behaviors
Spikes
(knowledge)
User Story
Non-functional
Requirements
Use Stories or
Actions
Bug / Defects
Constrains
(solving)
Fix
impediment

The beauty of a User Story
48
Acceptance Criteria:
-
-
 User stories are all about the role who interact with the system or
who realize some value or benefit from the system.
 Acceptance criteria are the specifications/conditions that must be
passed before the story is done and accepted by Product Owner

Why Use User Stories
 Keep yourself expressing in business value
 Avoid introducing details too early that
prevent design options and lock developers
into one solution
 Get to small enough chunks that invite
negotiation and movement in the backlog
 Leave the technical functions to the architect,
developers, testers, and so on
 It’s great for vertical slicing! (what?)
49

Life cycle Story
idea epic stories build & Value &
features Deploy
happy user
50
Low value
High Value

Refining and refining…
“as a credit card user I want to see all transactions of my payments”
“as a credit card user I want to see all transactions of my payments,
so that I have an overall view of my expanses”
AC: Amount, description, date, location, shop, bank account
“as a frequent credit card user I want to see transactions of my
payments, so that I have an overall view of my expanses”
AC: Amount, description, date, location, shop, bank account
AC: transactions overall view can go back to 16 months
51
50
30
12

INVEST (Definition of Ready for sprint)
52
Independent We want to be able to develop in any sequence.
Negotiable Avoid too much detail; keep them flexible so the team can
adjust how much of the story to implement.
Valuable Users or customers get some value from the story.
explained
Estimable The team must be able to use them for planning.
Business/complexity
Small Large stories are harder to estimate and plan. By the time
of iteration planning, the story should be able to be
designed, coded, and tested within the iteration.
Testable Document acceptance criteria, or the definition of done for
the story, which lead to test cases, PO needs to know
when it’s done

Check, check, check?
 User Story defined
 User Story Acceptance Criteria defined
 User Story dependencies identified
 User Story sized by DevelopmentTeam
 Scrum Team accepts User Experience artefacts
 Performance criteria identified, where appropriate
 Person who will accept the User Story is identified
 Team knows how to test it
 Team knows how to demo it
53

Piftfalls User Stories
 Too formal or too much detail. If a team sees a story at
iteration planning that looks like an IEEE requirements
document, they often assume that all the details are there and
will skip the detailed conversation.
 Technical tasks masquerading as stories. Much of the power
of Agile comes from having a working increment of software at
the end of each iteration. If your stories are technical tasks, you
do not end up with working software at the end of the sprint.
 Skipping the conversation (acceptance criteria). Stories are
intentionally vague before sprint planning. If you skip the
acceptance criteria conversation, you risk moving in the wrong
direction, missing edge cases or overlooking customer needs.
 Describing the how. The development team is responsible for
that.
54

Vertical slicing
56
UI/UX
Middleware
Back-end
Epic / Theme
online payment
Sprint 1
Sprint 2Sprint 3

Too big to handle
Stories that are to big…
… will dominate a sprint.
… are more difficult to understand.
… are more risky.
… are hard to estimate.
… make it hard to “see” progress.
… disturb the continue flow of delivering.
61

Vertical Slicing
Ways to split User Stories
1. Workflow steps
2. Business Rules
3. Happy/unhappy flows
4. Input options
5. Data types & Parameters
6. Operations
7. Roles
8. Test cases / Acceptance Criteria
62

Strategy: Split by workflow steps
 If user stories involve a workflow of some kind, the
item can usually be broken up into individual steps.
As customer I want to purchase the goods in my
shopping basket so that I can receive my
products at home
 What steps a user perform?
 Are all steps necessary (right now)?
 Can steps be simplified (for now)?
63
30

Strategy: Split by workflow steps
products at home
 As customer I want to log in with my account so I don't
have to re-enter my personal information every time;
 As customer I want to review and confirm my order, so I
can correct mistakes before I pay;
 As costumer I want to receive a confirmation email with
my order
64
30

Strategy: Business Rules
 If user stories involve a number of explicit or implicit
business rules. It can be split by give constrains
products at home
 What rules apply to this story?
 Are all business rules necessary (right now)?
 Can simpler rules suffice (for now)?
65
30

Strategy: Business Roles
shopping basket so that I can receive my products at
home
 As shop owner I want to decline orders below 10 dollars,
because I don't make any profit on them;
 As shop owner I want to decline customers from outside the
US, because the shipping expenses make these orders
unprofitable;
 As shop owner I want to reserve ordered products from stock
for 48 hours, so other customers see a realistic stock;
66
30

Strategy: Happy & Unhappy Flow
 Functionality often involves a happy flow and one or
more unhappy flows.
As customer I want to log in with my account so
that I can access secured pages;
 What does the happy/unhappy flow look like?
 Are all unhappy flows really necessary (right now)?
 Can unhappy flows be simplified (for now)?
67
30

Strategy: Happy & Unhappy Flow
 Functionality often involves a happy flow and one or
more unhappy flows.
As customer I want to log in with my account so
that I can access secured pages;
 As user I want to log in with my account, so that I can access
secure pages (happy);
 As user I want to be able to reset my password when my login
fails, so I can try to log in again (unhappy);
 As user I want to be given the option to register a new account if
my login is not known, so I can gain access to secure pages
(unhappy);
 As site owner I want to block users that log in incorrectly three
times in a row, so I can protect the site against hackers
(unhappy);
68
30

Strategy: Input Options / Platforms
 Many applications have to support various input
devices and/or platforms.
 Beware of your Definition of Done!
As customer I want to have a one total overall
view of all my expenses, so I can see how my
spending are divided.
 Which platforms are supported?
 Are all platforms necessary (right now)?
 Are some platforms harder than others?
69
30

Strategy: Input Options / Platforms
 Many applications have to support various input
devices and/or platforms.
 Beware of your Definition of Done!
As customer I want to have a one total overall
view of all my expenses, so I can see how my
spending are divided.
 As customer I want to have … on my iPAD
 As customer I want to have … on my Desktop
 As customer I want to have … on my iPhone
70
30

Strategy: Data & Parameters
 Some user stories can be split based on the
datatypes they return or the parameters they are
supposed to handle.
As customer I want to search for transaction so I
can view and check if I paid something.
 What data types are supported?
 Are all data types necessary (right now)?
 What parameters are relevant (for now)?
71
30

Strategy: Data & Parameters
 Some user stories can be split based on the
datatypes they return or the parameters they are
supposed to handle.
As customer I want to search for transaction so I can
view and check if I paid something.
 As customer I want to search on an given amount so I quickly
find the transaction
 As customer I want to search on an given period so I quickly find
the transaction
 As customer I want to search on an given account so I quickly
 As customer I want to search on an given category so I quickly
72
30

Strategy: Operations
 CRUD operations are very prevalent when
functionality involves the management of entities,
such as products, users or orders:
As FAQ owner I want to manage news items in the
app, so I can update FAQ information if it is changed.
(without updating the app)
 What operations does the story entail?
 Are all operations necessary (right now)?
 Can any operations be simplified (for now)? !
73
30

Strategy: Operations
 CRUD operations are very prevalent when
functionality involves the management of entities,
such as products, users or orders:
As FAQ owner I want to manage news items in
the app, so I can update FAQ information if it is
changed.
 As shop owner I want to add new products, so customers can
purchase them;
 As shop owner I want to update existing products, so I can adjust
for changes in pricing or product information;
 As shop owner I want to delete products, so I can remove
products that I no longer stock;
 As shop owner I want to hide products, so they cannot be sold
for the time being;
74
30

Strategy: Roles/Persona’s/Actors
 User stories often involves a number of roles (or
groups) that performs parts of that functionality
As news organization I want to publish new articles
on our homepage, so customers have a reason to
return periodically
 What roles are involved in this Story?
 Are all roles necessary (right now)?
75
30

Strategy: Roles/Persona’s/Actors
 User stories often involves a number of roles (or groups)
that performs parts of that functionality
As news organization I want to publish new articles on
our homepage, so customers have a reason to return
periodically
 As journalist I want to write an article, so it can be read by our
customers;
 As customer I want to read a new article, so I can be informed of
important events;
 As editor I want to review the article before putting it on the site,
so that we can prevent typos;
 As admin I want to be able to remove articles from the site, so
that we can pull offending articles;
76
30

Strategy: Test & Scenario's
 is useful when it is hard to break down stories based on
functionality alone.
 In that case, it helps to ask how a piece of functionality
is going to be tested. Which scenarios have to be
checked?
As manager I want to assign tasks to employees
in the planning tool, so the can work on tasks
 What tests are used to verify this story?
 What acceptance criteria apply?
 Are all test scenarios necessary (for now)?
77
30

Strategy: Test & Scenario's
 is useful when it is hard to break down stories based on
functionality alone.
 In that case, it helps to ask how a piece of functionality is
going to be tested. Which scenarios have to be checked?
As manager I want to assign tasks to employees in the
planning tool, so the can work on tasks
 Test case 1: If an employee is already assigned, he or she cannot
be assigned to another task;
 Test case 2: If an employee has reported in sick, he or she should
be visually marked so they can be ignored;
 Test case 3: If an employee has reported in sick, he or she cannot
be assigned to a task;
 Test case 4: If an employee is not yet assigned, they can be
assigned to a task;
78
30

Tools & Links
Cheat Sheet 8 examples of splitting:
http://35qk152ejao6mi5pan29erbr9.wpengine.netdna-
cdn.com/wp-content/uploads/2009/10/Story-Splitting-
Cheat-Sheet.pdf
Walk through split a story
http://www.agileforall.com/splitting-user-stories/
http://35qk152ejao6mi5pan29erbr9.wpengine.netdna-
cdn.com/wp-content/uploads/2012/01/Story-Splitting-
Flowchart.pdf
Good reading of the 8 examples of splitting:
http://blog.agilistic.nl/8-useful-strategies-for-splitting-
large-user-stories-and-a-cheatsheet/
83

Potential Concerns &
cope with dependencies
(back-ends/services)
84

Potential Concerns about splitting
Concerns
- reduced business value of the smaller items
- primary purpose of breaking down functionality is to reduce
risk, increase flow and increase the amount of working
functionality that can be reviewed every sprint.
- The alternative is to keep working with very large
chunks of functionality, with all the aforementioned
consequences and risks.
- cause more work instead of less.
- This acutely true. it's often easier to just keep working on a
piece of functionality until it's completely done instead of re-
visiting. No need to changes UI again, etc.
- Agile is all about continuously review and test our work and
adjust according to the feedback we get. Inspect & adopt
- If you don’t go to production often this feeling won’t go away.
85

Cope with dependencies (back-end & services)
- Short term mitigation:
- Build when dependent services are available in Test
- Pro: Have the first version quick
- Con: Lot’s of rework, delay on end version.
- Build when dependent services are available in Test and
stabilized
- Pro: Less rework, have the service pretty quick
- Con: Still rework
- Build when dependent services are available in Production
- Pro: Little rework
- Con: Limited in influence on changes of service
- Build when only service descriptions are available
- Pro: More influence on changes in needs, have a first
version pretty quick
- Con: Heaps of rework, end version probably is delayed
very long
86

Trust the team
88
Product
Owner
Dev Team
(max 9 )
Scrum
Master
Splitting &
slicing is a bit
scary in the
beginning

Swarming
UX
Front-
end
Business
Analist
tester
Business
Analist
Interaction
Designer
Developer
 Working together on
same story
 More elegant solution
 Finishing one user story
is better than working on
all and not finishing one
of them
Best solution!

90
“Type a quote”
-Name Surname

Db workshop - art of story splitting and writting

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Db workshop - art of story splitting and writting

Similar to Db workshop - art of story splitting and writting (20)

Db workshop - art of story splitting and writting

Editor's Notes