let's sharpen your agile ax, it's story splitting time

100
Let’s Sharpen Your Agile Ax: It’s Story Splitting Time Presented by Brian Sjoberg 8/25/2016 Developed by Ken Furlong and Brian Sjoberg

Upload: excella-consulting

Post on 13-Apr-2017

459 views

Category:

Software


4 download

TRANSCRIPT

Let’s Sharpen Your Agile Ax: It’s Story Splitting Time

Presented by Brian Sjoberg8/25/2016

Developed by Ken Furlong and Brian Sjoberg

• Agile/Lean Coach at Excella

• Focus on Org. Transformation

• DC Scrum User Group

Introduction

3

• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Splitting User Stories• Tracking & Reporting (Bonus)

Outline

• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Splitting User Stories• Tracking & Reporting

Outline

• An artifact to facilitate communication• User story is a way to represent a

customer’s request to the team that creates a product.

• Helps prevent misunderstanding• Best option so far

User Story

Create Shared Understanding

7

I’m glad we all agree.Credit: User Story Mapping

Create Shared Understanding

8

Oh!Credit: User Story Mapping

Create Shared Understanding

9

Ah Ha!Credit: User Story Mapping

Create Shared Understanding

10

I’m glad we all agree.Credit: User Story Mapping

To Do• Stand up server• Build database• Build API• Build UI• Perform QA• Deploy

1 2 34 5 67 8 9

0

+-x÷. =

S M Tu W Th F S1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

28 29 30 31

DesignDocuments

Doc

Doc

Doc

Doc

Doc

Doc

Doc

Doc

Doc

DesignDocuments

To Do• Stand up server• Build database• Build API• Build UI• Perform QA• Deploy

To Do

Stand up server

To Do

Build Database

To Do

Build API

To Do

Build UI

To Do

Perform QA

To Do

Deploy

S M Tu W Th F S

1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

28 29 30 31

S M Tu W Th F S

1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

28 29 30 31

S M Tu W Th F S

1 2 3 4 5 6

S M Tu W Th F S

1 2 3 4 5 6

7 8 9 10 11 12 13

S M Tu W Th F S

1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

S M Tu W Th F S

1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

1 2 3

4 5 6

7 8 9

0

+

-

x

÷. =

1 2 34 5 67 8 9

0

+

. =

1 2 34 5 67 8 9

0

+-

. =

1 2 34 5 67 8 9

0

+-x

. =

1 2 34 5 67 8 9

0

+-x÷. =

1 1 2 34 5 67 8 9

0.

1 2 3

4 5 6

7 8 9

0

+

-

x

÷. =

To Do• Stand up server• Build database• Build API• Build UI• Perform QA• Deploy

Value vs. Work

TaskA chunk of workthat is part of delivering a particular chunk of the product (value).

User StoryA chunk of the product (value) that customer recognizes as a part of the whole product (value) they requested.

Value vs. Work

User Stories (Product)• New search screen• Reset button on an

existing screen• Automation of a

manual business process

Tasks (Work)• Writing code • Setting up a database

table• Testing that the code

works• Security scanning

Where Does Information Live?

19

Search for SomethingAs a user, I want to be able to search for everything and get back exactly what I need and do it quickly So that I spend the least time possible finding exactly what I need.

Lorem ipsum dolor sit amet, mel ei alii alienum. Id ius graece commune constituto. Invidunt senserit sea no, id inani elitr indoctum mea, sed te molestie referrentur intellegebat. Dico nullam sententiae id pri, eos oratio populo vivendo cu. Elitr partiendo ei eam, ex pericula consequuntur mel.

No assum perfecto intellegebat nec, ius ex utinam graeco cotidieque. Mel ei erant tractatos, ea duo brute omnes voluptatum, pro nobis mucius virtute in. Per ponderum electram an, amet atqui aeterno et cum. Eos an oblique iuvaret, illum altera fierentnam at.

Ei summo affert vituperata his. Vel te option nonumes. Ne iracundia theophrastus usu, antiopam forensibus ex his. Has tantas vidisse democritum ut, primismollis expetendis vis ne, ei sit consul utamur repudiandae. Ea sensibus sadipscing eum.

Id viris convenire sed, id eirmod principes sit. Sed an eirmod deserunt similique. Te quot putent evertitur ius, an quo tantas nominavi explicari. Ex regione platonem mea, sed assum evertitur torquatos at, ne nostro moderatius definitiones per. Ne numquam debitis pri.

Legere theophrastus an mea, sed alterum platonem vituperata eu, dicta libris dicunt nam ei. Inermis invidunt interpretaris eu ius. Id sea reque errem, tollit pertinax expetendis te eum. Dicam volumus suscipiantur an duo, ne per elit salutatus, duo ei nemore concludaturque. Ei soluta admodum ius, ius an deleniti tincidunt. Reque nulla aliquid ut pri.

- The system shall respond in X amount of time with the search results

- Has error oratio in. Eam putent omittam salutandi no, virtutedetracto cu vel.

- Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel.

- Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel.- Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel.- Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel.- Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit.- Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit.- Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel.- Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel.- Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit.- Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit.- Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel.- Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel.- Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit.- Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit.

Acceptance Criteria

• Not all information lives in a user story.• There can be a lot of information we need

to capture and make available that do not belong in stories.

Where Does Information Live?

• Design style guide• Wireframes• Use Cases• Security standards• Test scenarios

Other Information

21

• Large chunks of work that don’t pertain to a particular user story

• Some use ‘technical user story’ and ‘research spike’– Work that cuts across multiple stories (e.g.,

setting up an environment)– Work that pertains to larger initiative but perhaps

not specific stories (e.g., research something)– Work that multiple folks will be collaborating on or

that needs to be visible to others

“Tech Stories”, “Spikes”

• Set up Jenkins for Continuous Integration• Set up Cucumber for Automated Acceptance

Testing

• Why does business care?– Jenkins – Improve health of code base that will

result in faster and more reliable release delivery– Cucumber – Improve code quality by catching

bugs earlier in development that will result in less defects and time to market

Tech Story Examples

23

• A larger, loosely defined user story that we expect to be broken down into smaller chunks and to be defined in progressively more detail as it gets closer to being built

• When an Epic is fully broken down into stories, the Epic could cease to exist (rather than serving as a category or “umbrella” for those stories)

Epics

Epics

25

Epic – Initial SearchSimple Search (No Perf)

Auto Complete Search

Suggestions after Search

Search (w/ Perf)

• A user story is a chunk of the __________.

• A task is a chunk of the ___________.

• A chunk of technical work that doesn’t pertain to a particular user story, ____________.

Review

• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Splitting User Stories• Tracking & Reporting

Outline

• As a _____________________________

• I want ____________________________

• So that ___________________________

Standard User Story FormatStarving Student on a Low Budget

to find and purchase food quickly from my mobile device

I can fill my stomach without spending a lot of money

WHO

WHAT

WHY

• As a _____________________________

• I want ____________________________

• So that ___________________________

Standard User Story FormatStarving Student on a Low Budget

to find and purchase food quickly from my mobile device

I can fill my stomach without spending a lot of money

Important to know Whom this work is going to benefit. We can more easily determine the best solution and uncover implicit needs.

It is critical to understand Why the Who wants the What they’re asking for. It greatly informs the final shape the solution will take and can help flag up flaws or unintended side effects in the design.

WHO

WHAT

WHY

What is most important? The Who, the What, or the Why?

1. Customer is the person/group requesting value from team building the product

2. Ideally, customers would write the user story for the team

3. Usually, an expert assists the customer in understanding what they really want/need

Notes about the customer

• Who is the “Who” in a user story?

• Is the “Who” ever the team doing the work, e.g., “As a developer, I want to go do something, so that I can do something else.”?

• Who typically writes the user story?

Review

• As a user, I want to use HTTPS so that my connection is secure.

Review

36

• As a developer, I need to determine a serialization strategy, so that I can send the API the data it needs.

Review

37

• As a mobile teen user, I want to search on my phone for music that I just heard on the radio so that I can listen to it again whenever I want.

Review

38

• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Splitting User Stories• Tracking & Reporting

Outline

• When the Definition of Ready (DoR) is met, the user story could be developed.

• The Definition of Ready applies to all of a team’s user stories and is more generic, e.g.:– Immediately actionable– Negotiable– Valuable– Estimated

– Sized-appropriatey

– Testable

When Can We Start?

Product Backlog Refinement

41

Definition of ReadyI N V E S T

Why is this needed?

• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Splitting User Stories• Tracking & Reporting

Outline

• When the Definition of Done (DoD) and Acceptance Criteria (AC) are both met, the user story is DONE.

• The DoD applies to all of a team’s user stories and is more generic

• AC pertain to a specific story

When Are We Finished?

DoD Example

All Code Checked-in

Unit Tests Passing

Acceptance Criteria Passing

Integration Test

Passing

Performance Test Passing

With a Product Back Item (PBI)

With a Sprint

With a ReleaseSecurity

Audit Passing

Regression Test

Passing

Continuously Improve DoD

All Code Checked-in

Unit Tests Passing

Acceptance Criteria Passing

Integration Test

Passing

Performance Test Passing

With a PBI

With a Sprint

With a ReleaseSecurity

Audit Passing

Regression Test

Passing

Continuous Im

provement

Continuously Improve DoD

All Code Checked-in

Unit Tests Passing

Acceptance Criteria Passing

Integration Test

Passing

Performance Test Passing

With a PBI

With a Sprint

With a Release

Security Audit

Passing

Regression Test

Passing

Continuous Im

provement

• Present Tense Indicative Statements, i.e., they are either TRUE or FALSE.

Acceptance Criteria

Correct• There is a button in

the upper left corner of the screen.

Present Tense Indicative Statements

Incorrect• Button in the upper left

corner of the screen• Put the button in the upper

left corner of the screen.• There will be a button in the

upper left corner of the screen.

• We need a button in the upper left corner of the screen.

• Present Tense Indicative Statements, i.e., they are either TRUE or FALSE

• Generally FALSE before the product has been built• Must be TRUE for the user story to be accepted• Include Functional and Non-Functional Requirements• Complete (All I See Is All There Is)• Un-ambiguous (no etc., TBDs)

Acceptance Criteria

Correct• The drop down

contains each of the days of the week.

• The screen loads in 1.5 seconds or less 95% of the time with strong 4G signal.

Unambiguous

Incorrect• The drop down

contains Monday, Tuesday, etc.

• Load time is sufficiently fast.

• Present Tense Indicative Statements, i.e., they are either TRUE or FALSE

• Generally FALSE before the product has been built• Must be TRUE for the user story to be accepted• Include Functional and Non-Functional Requirements• Complete (All I See Is All There Is)• Un-ambiguous (no etc., TBDs)• Speak in the language of an official Domain Model /

Glossary• Include Examples when helpful

Acceptance Criteria

• Determine if each of the following are well-formed acceptance criteria:– “New fields”– “Add the new fields to the JSON response.”– “The JSON response will contain a ‘Type’

field.”– “The JSON response contains a ‘Type’ field.”– “The JSON response is returned in less than

500 milliseconds 95% of the time with a strong 4G signal.”

Review

• If all of the acceptance criteria are TRUE, is the story accepted?

• Who determines whether the acceptance criteria are TRUE?

• What do we do if a story is partially done at the end of a day, week, iteration, or release?

Review

• If we are using story points, should the team receive some points for completing some of the work?

Review

NO PARTIAL CREDIT!

• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Splitting User Stories• Tracking & Reporting

Outline

• There are several “fault lines” along which you can split most stories.

• These fault lines usually appear pretty clearly in the acceptance criteria, if they are well-formed and complete

• Helpful to well-form a story before you split it too far– Until well-formed, it may appear irreducibly

complex when it really isn’t

Splitting Stories

Defer PerformanceAs a user, I can search for flights between two destinations

...(slow - just get it done, show a “searching” animation).

...(in under 5 seconds).

Examples of Splitting Stories

Operations (e.g. CRUD)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.

Major EffortAs a user, I can pay for my flight with VISA, MasterCard, Diners Club, or Amex.

...I can pay with Visa.

...I can pay with all four credit card types (VISA, MC, DC, AMEX).

Examples of Splitting Stories

Data Entry MethodsAs a user, I can search for flights between two destinations.

...using simple date input.

...with a fancy calendar UI.

• Well defined Acceptance Criteria (AC) for a large story can typically be broken down into smaller stories with own AC

• Example AC– I can create a user– I can delete a user– I can update a user’s information

Acceptance Criteria Splitting

Credit: SmallerStories.com

• Form groups of 3• Discuss ways to split one or more of the

stories on the worksheet

Group Exercise

• Look for connector words:– And, Or, If– When, But, Then– As well as, Commas

Conjunction Splitting

Credit: SmallerStories.com

• Form groups of 3• Discuss ways to split one or more of the

stories on the worksheet

Group Exercise

• Look for words that could be replaced with more specific terms– Nouns, verbs, adjectives, adverbs can all be

generic– For example

• Vehicle -> Car -> Honda Civic• Animal -> Dog -> Pug

Generic Words Splitting

Credit: SmallerStories.com

• Form groups of 3• Discuss ways to split one or more of the

stories on the worksheet

Group Exercise

• Pretend User Story is done• What happens when the functionality is

used?• If there is a sequence, then it may be

possible to break into smaller stories

Timeline Analysis Splitting

Credit: SmallerStories.com

• Form groups of 3• Discuss ways to split one or more of the

stories on the worksheet

Group Exercise

• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Splitting User Stories• Tracking & Reporting

Outline

Tracking & Reporting

Things

Things we track in a tool

Things we

report on

• User Story• Task• Spike• Meeting• Epic• Administrivia

Where does each type of thing fall?

How do we measure the factory?

How do we measurethe flow in the factory?

To Do Doing Done

To Do Doing Done

To Do Doing Done

To Do Doing Done

To Do Doing Done

To Do Doing Done

When will we be done?

To Do Doing Done

To Do Doing Done

To Do Doing Done

To Do Doing Done

To Do Doing Done

To Do Doing Done

Let’s Wrap Up

• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Splitting User Stories• Tracking & Reporting

Let’s Wrap Up

• Comments/Feedback– [email protected]– 301-404-0765

Thank You

Back Up

105

• Card – Small and could fit on a 3” x 5” card

• Conversation – It is placeholder for a conversation to occur in the future. Pointer to other documents

• Confirmation – Objectives identified through conversation are placed here.

Three C’s of User Stories

106

• We track chunks of the product/value in a cumulative flow diagram (CFD)

• It is critical to maintain the discipline of not creating user stories that aren’t chunks of value.

• If there is an optics problem with capacity drains, we need to solve that in a different way.

Cumulative Flow

What is this telling us?

What is this telling us?

What is this telling us?

What is this telling us?

• Anything outside the teams control that prevents the team from making progress

• Many use ‘impediment’ to denote anything outside the team’s control that fully blocks or just slows them down.

• When a blocker or a lesser impediment is identified, the team should escalate the issue so that it can be resolved.

Blockers