db workshop - art of story splitting and writting

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!

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

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

How project variables are set

Always7%

Often13%

times16%Rarely

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

The product owner...

The backlog will be like…

Product Statement and Core Values.

Product Statement & Core Values

Company Statement & Values

Target audienc

Product StatementCore

ValuesPersona

’sactors

Core ActivitiesUser Story User Story

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!

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

Example 2: Blizzard Entertainment:

“DEDICATED to creating the most epic entertainment experience

EVER”

ADP | Product Owner Training | Codecentric | Phil van Dulm

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

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

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

Know your users, actors, and stakeholders.

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

Core activities of the users and actors

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

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.

Story Telling

Walking Skeleton

Story Telling & Walking Skeleton

Actors/Persona’s & Core Activities

Actor 1 activity

Actor 2 activity

Story Telling and Walking Skeleton

Sequential in Time

Actor 1 activity

Task / user story

sub-tasks

Actor 1 activity

2Actor 2 activity

Task / user story

Task / User story

Task details

Less optional

More optional

Example Credit Card

Credit card owner /

checking transaction

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

Show total spend

Explain: Why is this

important! What is the need of the costumer?

Sequential in Time

y Explain: Why

is this important!?What is the need of the costumer?

Credit card owner /

checking transaction

Credit Card owner /

checking credit

show transaction

details

Show remaining

credit

Example Credit Card

Show reservations

Choose month and

show transactions

Show total spend

Sequential in Time

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

Release 2

Release 3

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

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

Product Backlog Items

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

Valid Product Backlog Items

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

The beauty of a User Story

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

Life cycle Story

idea epic stories build & Value & features Deploy happy user

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 accountAC: transactions overall view can go back to 16 months

INVEST (Definition of Ready for sprint)

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

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.

Vertical Slicing

Vertical slicing

Middleware

Back-end

Epic / Theme online payment

Sprint 1Sprint 2Sprint 3

Vertical slicing

Release often

Splitting Stories

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.

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

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

Strategy: Split by workflow 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

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

Strategy: Business Roles

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;

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

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

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?

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

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

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

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

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;

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

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;

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

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;

Some Tools & Links

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/

Potential Concerns &cope with dependencies

(back-ends/services)

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.

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

End note

Trust the team

Product Owner

Dev Team

(max 9 )

Scrum Master

Splitting & slicing is a bit scary in

the beginning

Swarming

Front-end

Business Analist

tester

Business Analist

Interaction

DesignerDevelope

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!

“Type a quote”-Name Surname

db workshop - art of story splitting and writting

Documents

writting proposal

business proposal writting

tech writting

10 effective writting`

053-creative writting

for writting

writting test

paragraph writting

thesis writting orientation

writting letter tips

reading and writting

factual writting

virus writting

booklet arabic writting

situational writting format

reading, writting, grammar

writting research

creative writting _ poems

medical writting

technical report writting