db workshop - art of story splitting and writting
TRANSCRIPT
WorkshopSlicing and Splitting StoriesThe art of slicing and splitting Stories and deliver value every sprintPhil 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 owner2. Product Statement & core Values3. Persona’s and Actors4. Core activities Persona’s Actors5. Story Telling & Walking Skeleton6. MVP and Release management7. Product Backlog items8. User stories & Acceptance Criteria9. Vertical Slicing & Splitting10.Tools, Links, Concerns and end note
4
How project variables are set
5
6
Always7%
Often13%
Some-
times16%Rarely
19%
Never45%
How do you know a (sub)feature will be used?…a waste of
money!
… probably a waste of money!
…Value for money!
Target business
goals
8
The product owner...
9
10
The backlog will be like…
11
12
Product Statement and Core Values.
13
Product Statement & Core Values
Company Statement & Values
Goals
Target audienc
e
Product StatementCore
ValuesPersona
’sactors
Core ActivitiesUser Story User Story
14
Product Statement & Core Values
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
Product Statement & Core Values
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
Product Statement & Core Values
Example 2: Blizzard Entertainment:
“DEDICATED to creating the most epic entertainment experience
EVER”
17
Product Statement & Core Values
ADP | Product Owner Training | Codecentric | Phil van Dulm
18
Product Statement & Core Values
Eight core values1. Gameplay FIRST2. Commit tot QUALITY3. Play nice; PLAY FAIR4. Embrace your INNER GEEK5. Every voice MATTERS6. Think GLOBALLY7. Lead RESPONSIBLY8. Learn & GROW
http://us.blizzard.com/en-us/company/about/mission.html
ADP | Product Owner Training | Codecentric | Phil van Dulm
19
Product Statement & Core Values
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 & Save2. Fast & Simple3. Real time
20
Product Statement & Core Values
21
Core Values Deutsche Bank (Spain?)
Product Statement & Core Values
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
28
Story Telling
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
30
31
Walking Skeleton
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
2Actor 2 activity
Task / user story
Task / User story
Task details
Nece
ssity
Less optional
More optional
Example Credit Card
34
Story Telling and Walking Skeleton
35
Credit card owner /
checking transaction
s
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
Nece
ssit
y Explain: Why
is this important!?What is the need of the costumer?
Story Telling and Walking Skeleton
36
Credit card owner /
checking transaction
s
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
Nece
ssit
y
37
The backbone Actors / persona’s Core activities Epics / ThemesThe 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
39
MVP
Release 2
Release 3
40
41
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
Nece
ssity
R1R
2R3
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
Product Backlog Items
44
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
47
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
The beauty of a User Story
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
The beauty of a User Story
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 accountAC: transactions overall view can go back to 16 months
51
50
30
12
The beauty of a User Story
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
The beauty of a User Story
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
The beauty of a User Story
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
55
Vertical slicing
56
UI/UX
Middleware
Back-end
Epic / Theme online payment
Sprint 1Sprint 2Sprint 3
Vertical slicing
57
Vertical slicing
58
Release often
59
Splitting Stories
60
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 Stories1. Workflow steps2. Business Rules3. Happy/unhappy flows4. Input options5. Data types & Parameters6. Operations7. Roles8. 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
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
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
As customer I want to purchase the goods in my shopping basket so that I can
receive my 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
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
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 find the transaction
As customer I want to search on an given category so I quickly find the transaction
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
Some Tools & Links
79
Tools & Links
80
Tools & Links
81
82
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 storyhttp://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
End note
87
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
DesignerDevelope
r
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