Finding the 'Seams': Making User Stories Smaller

AW6
Agile Requirements
6/7/2017 1:30:00 PM
AW6 Finding the 'Seams': Making User
Stories Smaller
Presented by:
Mitch Goldstein
Summa
Brought to you by:
350 Corporate Way, Suite 400, Orange Park, FL 32073
888-‐268-‐8770 ·∙ 904-‐278-‐0524 - info@techwell.com - https://www.techwell.com/

Mitch Goldstein
Summa
Summa Technologies' first technical agile coach, Mitch Goldstein has more than
thirty years of experience in the software development industry, working with
agile principles and teams since they came into common use. A pioneer of object-
oriented development, enterprise platforms, and Java user interface
development, he has spent years honing his craft as a consultant for investment,
accounting, insurance, and healthcare organizations. A published author and
technical journalist, Mitch has transitioned from developer to an agile coach,
focused on creating high-performance teams and transitioning organizations to
the Scaled Agile Framework. Mitch lives just east of Pittsburgh, where he and the
city have happily adopted each other.

5/23/2017
1
Finding the ‘Seams’
Making User Stories Smaller
Mitch Goldstein
Technical Agile Coach,
Summa Technologies
2agile@summa.com©2017 Summa Technologies – All Rights Reserved
The Ancient Art of
Storytelling

5/23/2017
2
When you look back throughout history, stories have always played an
important part in our lives... Telling stories was our way to pass along
information across generations to make sure that history and facts
weren’t lost. It was also a way for us to make sense of the world
around us. To find a way to explain what we didn’t understand, the
things we feared and that which we desired. Storytelling in various
forms and shapes helped us make what we were going through more
tangible. Through telling stories we were able to give others a glimpse
into what had happened and share that which we believed to be the
truth about the world we lived in. It was both a way to educate and
entertain, but also a way to pass on and instill moral values.
Source: Storytelling in Design - Principles and Tools for Defining, Designing and Selling Multi-
Device Design Projects - Anna Dahlström, O'Reilly Media, Inc., 2017 (Early Release)
Copyright © 2016 Anna Dahlström
 Stories have a beginning, middle and end.
• Also frequently have ‘epilogs’ (aka ‘retrospectives’)
 Product Owners are the storytellers
 “Once upon a time” = “As a <role> I need so & so”
 Roles are the characters in the story
 Value proposition is the plot of the story
 “Happily ever after” = Definition of Done
Why Stories?

5/23/2017
3
 Too short – gives sensation of incompleteness
 Too long – gives sensation of underestimation
 Just right – About as long as a decent jokes
 Jokes also have beginnings, middles and ends
 Thus we have:
How big should stories be?
Like Goldilocks in search of a comfortable bed, some stories can be
too big, some can be too small, and some can be just right. Story
size does matter because if stories are too large or too small you
cannot use them in planning. Epics are difficult to work with because
they frequently contain multiple stories. For example, in a travel
reservation system, “A user can plan a vacation” is an epic. Planning a
vacation is important functionality for a travel reservation system
but there are many tasks involved in doing so. The epic should be
split into smaller stories. The ultimate determination of whether a
story is appropriately sized is based on the team, its capabilities,
and the technologies in use.
Source: User Stories Applied for Agile Software Development
Mike Cohn, Addison-Wesley 2004

5/23/2017
4
Why ‘small’?
 Compulsory Group Exercise (not really compulsory)
 Please close your eyes and focus on the image that
comes into your mind when I read a list of words…
Is this a stone or a rock?

5/23/2017
5
 Mountain, Boulder, Slab, Stone, Pebble, Gravel, Sand
 Same composition, density, atomic structure‡
 Different mass‡ and different purposes
 Think of the value of ‘Fibonacci’
 What can you build out of boulders? Slabs? Stones?
• Whatever it is – it will be a long term project and require many resources and
much coordination (Hint: this is bad if you want to be high-performing)
• Lighter Material + Faster Building = Cheaper Value
Is this a stone or a rock? (Epilog)
‡Roughly speaking, I am not a real geologist
Reduced batch size gives:
‒ Reduced cycle time
 Little’s Law: 𝑊 = 𝐿
𝜆
‒ Reduced variability of flow
‒ Reduced risk
‒ Reduced overhead
‒ Accelerated (continuous) feedback
‒ Increases value flow efficiency
Along Comes Reinertsen
Photo Source:
https://www.flickr.com/photos/lean-tribe

5/23/2017
6
Larger batch sizes cause:
‒ Uncertainty in estimation
‒ WIP nightmares (see right)
‒ More test cases per story
‒ Cost and duration growth
‒ Difficulty in correcting and
adjusting planning
‒ Lower motivation and urgency for
completion
What is wrong with large batches?
Photo Source: WikiMedia Commons
Reducing batch sizes reduces the amount of work-in-process
inventory (WIP). Not only does this reduce inventory-carrying
costs, but also production lead-time or cycle time is
approximately directly proportional to the amount of WIP.
Therefore, smaller batch sizes shorten the overall production
cycle, enabling companies to deliver more quickly and to
invoice sooner (for improved cash flow). Shorter production
cycles increases inventory turns and allows the company to
operate profitably at lower margins, which enables price
reductions, which increases sales and market share.
Source: Jerry Kilpatrick, “Lean Principles” © 2003 Utah
Manufacturing Extension Partnership

5/23/2017
7
Are you INVESTed in
your user stories?
Source: Wake, William C. “INVEST in Good Stories, and SMART Tasks.”
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Independent
Negotiable
Valuable
Estimable
Small
Testable
I
N
V
E
S
T
• If you can’t estimate it – it’s not a user story
• Size is always estimated iteratively
• Refined as we learn more about the story’s details
• Adjusted as other situations change
• ESTIMATES ARE NEVER CAST IN STONE
• Estimates are not intended to be perfect
• Over time, estimate error tends to wash out of productivity
• Accuracy of individual estimates should never be a
performance indicator
User Stories are Estimable

5/23/2017
8
 Common anti-pattern in maturing agile teams
 Rooted in
• Fear of failure, fear of being ‘wrong’
• Compulsion to achieve more than is realistic
• Concerns about unpredictability
• Anxiety about job or position loss
 Smaller estimates are less intimidating and less
prone to error!
Estimation Angst
• Big stories are hard to understand, hard to estimate, hard to
finish
• Complex problems MUST be broken down to simpler ones to
be solvable in steps
• Large stories (5+) always cause issues when they appear on a
sprint plan
• Keep actionable stories to 1, 2, 3, 4 points when possible
• Iterative elaboration is how to split stories for better
consumption
User Stories are Small

5/23/2017
9
Splitting Stories
• Smaller stories have a higher success rate of moving
across the (real or virtual) Kanban board
• Easier to test and demo
• Faster move through to QA, minimize QA idleness
• Shorter stories mean more sprint flexibility when
conditions change
• Smaller stories fit better within sprint boundaries
• Stories should be completed in one sprint
• Story-like things that are bigger are Features, Capabilities, Epics
Why do we split stories?

5/23/2017
10
AND BOTH MULTIPLE DIFFERENT OR
ALSO MANY WITH THEN VARIOUS NEXT
WHEN SEPARATE SIMILAR LIKE UNLIKE
DIVERSE MIXED IDENTICAL ALIKE
CERTAIN AFTER BEFORE
List of Seam Words (incomplete)
• Some words are a dead giveaway that a story
needs to be split – these we call ‘seam words’:
• They imply (indirectly) that there are multiple value
statements within a single story
• Solution: separate the value statements into their
own stories!
• Use iterative elaboration to make stories smaller
and more complete
Watch out for those Seam Words!!

5/23/2017
11
Seam Word Examples
As an Admin I want to
change passwords for
internal and external
users
As a Manager I can
export various reports
to a spreadsheet
As a Sales User I can
sort results by different
sales regions and
demographics
As an Auditor I can
review the account
activity for many kinds
of users
As a Marketer I can
sort results by certain
ZIP code and sales
regions
As a Manager I can
show identical views
for like employees
As a Coach I need
separate lists for each
team in my program
As an Admin I can
remove users after Ops
is informed they are no
longer with us
Seam Word Examples - Highlighted
As an Admin I want to
change passwords for
internal and external
users
As a Manager I can
export various reports
to a spreadsheet
As a Sales User I can
sort results by different
sales regions and
demographics
As an Auditor I can
review the account
activity for many kinds
of users
As a Marketer I can
sort results by certain
ZIP code and sales
regions
As a Manager I can
for like employees
As a Coach I need
separate lists for each
team in my program
As an Admin I can
remove users after Ops
is informed they are no
longer with us

5/23/2017
12
Splitting on the Seams – Is it a Feature?
FEATURE: As an
Auditor I can review
the account activity for
many kinds of users
As an Auditor I can
review the account
activity for the most
common user
As an Auditor I can
review the account
activity for the second
most common user
SPIKE: Figure out how
many kinds of user
there are and which are
the most common.
As an Auditor I can
review the account
activity for the third most
common user, etc.
 Split to smaller stories (and/or spikes)
 Split to acceptance criteria (and/or spikes)
 Split to out-of-scope (spike to ascertain?)
 Split by testing requirements (different conference)
 Spike to split (iterative elaboration‡)
 Modularization
• Architectural decision (different conference)
Splitting Techniques
‡More on this in a couple of slides…

5/23/2017
13
Splitting on the Seams – Is it a Criterion?
many types/views there
are and how to tell
views are identical.
• Gather information!
• Analyze the criteria
As a Manager, I want to have
consistent views for the two most
common employee types so that I
can interpret them consistently and
compare them accurately.
GIVEN Manager Role Access
WHEN the salaried and hourly
employee views are compared
THEN the views will be identical
upon [visual inspection | automated
test] in content and style
As a Manager I can
for like employee types
Splitting on the Seams – Is it in Scope?
many types/views there
are and how to tell
views are identical.
• Gather information!
• Analyze the criteria
As a Manager I can
for like employee types
Team
Product
Owner
We were hoping
you would say
that!
Not needed
for EVERY
type…

5/23/2017
14
Iterative Elaboration
 Ideas come first
 Outline comes next
 Fill in outline with more information
 Drafts are reviewed
 Changes are made, estimates created/updated
 Repeat until definition of ready
 Use Iterative Elaboration
User Stories must be ‘written’

5/23/2017
15
 A technique to go from a very general idea to a very
specific user story
 User stories will start of in the ‘larval’ state
• Incomplete narrative, incomplete acceptance criteria
• Stories become more ‘real’ with each elaboration
• Estimates become more obvious with each elaboration
• Risks and dependencies also grow with understanding
 User stories don’t start as ready
What is Iterative Elaboration?
Use the 3C’s Technique
Card Conversation Confirmation
As an Admin I want
the ability to
unlock user
accounts so they
can reset their
passwords
How will users
request an unlock?
There will be a
special e-mail
account…
GIVEN a locked user
account
WHEN a locked user
sends a request
THEN . . .

5/23/2017
16
 Start with 3C’s
 Read it out loud to the team
 Add a little bit of information each time
 Move on to another story
 Set up times for appropriate people to define and refine
stories – set a time and story limit
 Make time to spend with people who can answer your
questions – take advantage of spikes!
 “Iteration is better than rumination”
Using 3C’s Iteratively
Conclusion

5/23/2017
17
Fluit, fluit, die storie is uit. (Afrikaans)
Aamaar kothati furolo; Note gaachhti murolo.
(Bengali)
и три дни яли, пили и се веселили
(Bulgarian)
Snipp snapp snut, så var sagan slut. (Swedish)
Source: https://en.wikipedia.org/wiki/Once_upon_a_time
… and they lived happily ever after.
Thank you!!

5/23/2017
18
Summa’s Agile Practice
Mitch Goldstein
Technical Agile Coach,
Summa Technologies
Email: mitch@summa.com
I tweet at @MitchSumma
I blog at summa.com/blog
611 William Penn Place
Suite 1200
Pittsburgh, PA 15219
agile@summa.com
Summa is a digital solutions consultancy that
combines its human-centered design, strategy
and agile software development capabilities to
power businesses and deliver engaging
customer experiences.

Finding the 'Seams': Making User Stories Smaller

Recommended

Recommended

More Related Content

Similar to Finding the 'Seams': Making User Stories Smaller

Similar to Finding the 'Seams': Making User Stories Smaller (20)

More from TechWell

More from TechWell (20)

Recently uploaded

Recently uploaded (20)

Finding the 'Seams': Making User Stories Smaller