No, this is not a well-formed acceptance criterion because it is not a present tense indicative statement that can be clearly determined as true or false. It does not provide enough information to determine if the requirement has been met.

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

3. • Agile/Lean
Coach at Excella
• Focus on Org.
Transformation
• DC Scrum User
Group
Introduction
3

4. • 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

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

6. • 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

7. Create Shared Understanding
7
I’m glad we all agree. Credit: User Story Mapping

8. Create Shared Understanding
8
Oh! Credit: User Story Mapping

9. Create Shared Understanding
9
Ah Ha! Credit: User Story Mapping

10. Create Shared Understanding
10
I’m glad we all agree. Credit: User Story Mapping

11. To Do
• Stand up server
• Build database
• Build API
• Build UI
• Perform QA
• Deploy
1 2 3
4 5 6
7 8 9
0
+
-
x
÷. =
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
Design
Documents

12. Doc
Doc
Doc
Doc
Doc
Doc
Doc
Doc
Doc
Design
Documents

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

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

15. 1 2 3
4 5 6
7 8 9
0
+
-
x
÷. =
1 2 3
4 5 6
7 8 9
0
+
. =
1 2 3
4 5 6
7 8 9
0
+
-
. =
1 2 3
4 5 6
7 8 9
0
+
-
x
. =
1 2 3
4 5 6
7 8 9
0
+
-
x
÷. =
1 1 2 3
4 5 6
7 8 9
0.

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

17. Value vs. Work
Task
A chunk of work
that is part of
delivering a
particular chunk of
the product (value).
User Story
A chunk of the product
(value) that customer
recognizes as a part of the
whole product (value) they
requested.

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

19. Where Does Information Live?
19
Search for Something
As 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 fierent
nam at.
Ei summo affert vituperata his. Vel te option nonumes. Ne iracundia theophrastus usu, antiopam forensibus ex his. Has tantas vidisse democritum ut, primis
mollis 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, 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.
- 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

20. • 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?

21. • Design style guide
• Wireframes
• Use Cases
• Security standards
• Test scenarios
Other Information
21

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

23. • 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

24. • 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

25. Epics
25
Epic – Initial Search
Simple Search (No Perf)
Auto Complete Search
Suggestions after Search
Search (w/ Perf)

26. • 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

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

28. • As a _____________________________
• I want ____________________________
• So that ___________________________
Standard User Story Format
Starving 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

29. • As a _____________________________
• I want ____________________________
• So that ___________________________
Standard User Story Format
Starving 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?

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

31. • 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

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

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

34. • 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

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

36. • 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?

37. Product Backlog Refinement
41
Definition of Ready
I N V E S T
Why is this
needed?

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

39. • 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?

40. 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 Release
Security
Audit
Passing
Regression
Test
Passing

41. 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
ContinuousImprovement

42. 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
ContinuousImprovement

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

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

45. • 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

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

47. • 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

48. • 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

49. • 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

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

58. NO PARTIAL CREDIT!

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

60. • 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

61. Defer Performance
As 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.

62. Major Effort
As 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 Methods
As a user, I can search for
flights between two
destinations.
...using simple date input.
...with a fancy calendar UI.

63. • 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

64. • Form groups of 3
• Discuss ways to split one or more of the
stories on the worksheet
Group Exercise

65. • Look for connector words:
– And, Or, If
– When, But, Then
– As well as, Commas
Conjunction Splitting
Credit: SmallerStories.com

66. • Form groups of 3
• Discuss ways to split one or more of the
stories on the worksheet
Group Exercise

67. • 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

68. • Form groups of 3
• Discuss ways to split one or more of the
stories on the worksheet
Group Exercise

69. • 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

70. • Form groups of 3
• Discuss ways to split one or more of the
stories on the worksheet
Group Exercise

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

72. 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?

74. How do we measure the
factory?

76. How do we measure
the flow in the factory?

77. To Do Doing Done

78. To Do Doing Done

79. To Do Doing Done

80. To Do Doing Done

81. To Do Doing Done

82. To Do Doing Done

83. When will we be done?

84. To Do Doing Done

85. To Do Doing Done

86. To Do Doing Done

87. To Do Doing Done

88. To Do Doing Done

89. To Do Doing Done

90. Let’s Wrap Up

91. • 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

92. • Comments/Feedback
– Brian.Sjoberg@Excella.com
– 301-404-0765
Thank You

93. Back Up
105

94. • 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

95. • 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

96. What is this telling us?

97. What is this telling us?

98. What is this telling us?

99. What is this telling us?

100. • 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