user story and splitting workshop
TRANSCRIPT
User Story and Splitting Workshop
Presented by Brian Sjoberg5/4/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• Examples• Splitting User Stories• Tracking & Reporting
Outline
• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Examples• 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
Epic Example
25
Epic – Initial SearchSimple Search (No Perf)
Auto Complete Search
Suggestions after Search
Search (w/ Perf)
• Meetings• Training• Administrivia• Status Reporting• Etc.
• Typically don’t create artifacts to represent/track Capacity Drains
Capacity Drains
• 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, ____________.
• Discuss: how should we handle a large capacity drain from an optics perspective?
Review
• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Examples• 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
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
• Bad User Stories• Good User Stories• Why?
Group Exercise
32
• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Examples• 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
36
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• Examples• Splitting User Stories• Tracking & Reporting
Outline
• When the Definition of Done (DoD) and Acceptance Criteria are both met, the user story is DONE.
• The Definition of Done applies to all of a team’s user stories and is more generic, e.g.:– “All unit tests are passing.”– “Code has been code reviewed.”– Other Standards (e.g. Perf and Load Tests passing)
• Acceptance Criteria pertain to a specific story, e.g.:– “Search displays results (w/o pictures) in 2 seconds or less
on 4G connection on iOS and Android mobile devices” – “The background of the pop-up window is magenta.”
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 on 4G connection.
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
• Bad Acceptance Criteria• Good Acceptance Criteria• Why?
Group Exercise
47
• 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• Examples• Splitting User Stories• Tracking & Reporting
Outline
Examples
• “The system converts the temperature to Celsius and displays the result.”– There can be no ambiguity – it’s a known
mathematical formula. For example, 59°F is always 15°C
• Then this happens:
Consider thisTakeaway #1
Just because something is unambiguous doesn’t mean there aren’t details or edge cases that require lots of
attention and thought!
Takeaway #2
Most bugs aren’t really bugs. They’re design flaws.
• A fantastic tool to aid the design process is the “Given, When, Then” format, popularized by Behavior Driven Development (BDD) and such tools as Cucumber, JBehave, SpecFlow.
• Given = user context (system state)• When = an event• Then = the expected outcome
Given… When… Then…
Given I am using the temperature conversion tool.When I supply a <Temp in F>Then the system displays the <Temp in C> rounded to the nearest tenth of a degree.
Examples:
Temperature Conversion
| Temp in F | Temp in C || -20 | -28.9 || 10 | -12.2 || 32 | 0 || 40 | 4.4 || 58 | 14.4 |
Given I am using the calculator appWhen I add <First Value> to <Second Value>Then I get this <Result>
Examples:
Another Example
| First Value | Second Value | Result || 2 | 2 | 4 || 5 | 5 | 10 || 3 | -2 | 1 || A | B | Error || 1.1 | 1.1 | 2.2 |
• Types of Issues (User Stories, Tasks, etc.)• User Story Syntax• Definition of Ready• Definition of Done & Acceptance Criteria• Examples• 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.
• 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
• 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
• 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• Examples• 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• Examples• Splitting User Stories• Tracking & Reporting
Let’s Wrap Up
Back Up
93
• 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
94
• 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