The document discusses user stories in agile requirements. It defines user stories, explains their components and purpose. User stories allow capturing high-level requirements without extensive upfront details. Additional details are gathered later as needed. The document also covers best practices for user stories, such as keeping them independent, negotiable, valuable, estimable, appropriately sized, and testable. It warns against potential issues and provides examples of decomposing large stories.
2. Introduction and Agenda
‣ Steve Davis, Davisbase Consulting
‣ 11 years of Agile Experience
‣ 5 years of Agile Training and Coaching Experience
‣ Work with teams from many industries
‣ Agenda
‣ What are User Stories?
‣ Why User Stories are used?
‣ The components of a good User Story
‣ Wrap up and Q&A
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
3. What Are User Stories?
• User Story
• Avery high-level definition of a requirement, containing just
enough information so that the developers can produce a
reasonable estimate of the effort to implement it (Kent
Beck)
• A promise for a discussion
• Usually stated in this format:
• As a <user role> I want <functionality> so that
desired benefit
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
4. User Story Example
As a patient, I want to access
test results online, so that I A small piece of business
can get them at my value that can be delivered
convenience without calling
my doctor. in an iteration
• Ron Jeffries defines user stories as consisting of three parts:
• Card: The description of the need
• Conversation: The conversation to follow that will cover the details
• Confirmation: The tests that confirm the story s satisfactory completion
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
5. Agile Requirements
Focus on the Customer - User Stories
• Agilerequirements are written
As an instructor,
from a customer s perspective, in I want to post my presentation
plain language to minimize the online
so that I do not need to send it.
barrier to customer involvement.
• Understandingthe why can be as
important as the what.
As a patient,
I want to access test results
online,
• Information gems exist in knowing so that I can get them at my
why our customers want what convenience without calling my
doctor.
they ask for.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
6. Agile Requirements
Focus on the Customer - User Stories
Who
As an instructor,
I want to post my presentation
What
online
so that I do not need to send
it.
Why
Who
As a patient,
I want to access test results
What
online,
so that I can get them at my
convenience without calling
Why
my doctor.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
7. Agile Requirements
Focus on the Customer - User Stories
Traditional Requirements!
Agile Requirements!
(no “why” included)!
As an instructor,
I want to post my presentation
Ability for user to post a
online
presentation online.
so that I do not need to send
it.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
8. Why User Stories?
• User
Stories allow the team to capture the requested features
without investing long periods of time defining details that may
change during development.
• Userstories are not meant to represent all of the information
the team will need in order to develop the feature.
• Theyare simply placeholders for a future conversation where
the team will define the deep detail necessary to develop the
feature.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
9. LEAN
Continuous, Just In Time
PRINCIPLE
Requirements Elaboration
Parts Warehouse
Manufacturing
!
Shock Absorber
Need new
Shock
?
Absorber
X 1,000,000’s
NEW Shock Absorber
X Just what we
Just In Time Inventory Meant:
need right now
Best Available Parts | No Risk of Waste
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
10. User Stories Are Created at the
Beginning of an Agile Project
PRODUCT BACKLOG
All User High-level requirements that will require additional detail for development
Stories
User stories are estimated and prioritized to drive a release plan
Example: Product will need user stories A - O completed before releasing
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
11. Additional Detail Is Gathered,
But Only Right Before Its Needed
PRODUCT BACKLOG
All User High-level requirements that will require additional detail for development
Stories
User stories are estimated and prioritized to drive a release plan
Example: Product will need user stories A - O completed before releasing
ITERATION 1
ITERATION 2
ITERATION 3
ITERATION 4
ITERATION 5
Story A Story D Story H Story J Story M
DETAILED REQS
DETAILED REQS
DETAILED REQS
DETAILED REQS
DETAILED REQS
Story B Story E Story I Story K Story N
Story C Story F Story L Story O
Story G
A, B, C
D, E, F, G
H, I
J, K, L
M, N, O
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
12. What are the components
of a good user story?
• INVEST acronym (Bill Wake)
• Independent
• Negotiable
• Valuable
• Estimable
• Sized appropriately
• Testable
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
13. UserINVEST
Stories
As a patient, I want to access test
results online, so that I can get
Independent
them at my convenience without
calling my doctor.
• Avoid dependencies with other
stories whenever possible
• Ableto deliver as a product
increment independently
As a patient, I want to login to my
online account so that I can see
my account information securely.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
14. UserINVEST
Stories
As a patient, I want to access test
results online, so that I can get
them at my convenience without
Negotiable
calling my doctor. • Storiesare NOT a contract,
break them up or add additional
stories or information if necessary
• Too much detail up front gives
As a patient, I want to
access all past test results online, the impression that more
so that I can get them at my discussion later is not necessary
convenience without calling my
doctor.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
15. UserINVEST
Stories
Valuable
• Should show value to:
• Users
• Customers
• Stakeholders
• Theagile team needs to maintain awareness of the
subjective nature of value
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
16. UserINVEST
Stories
Estimable
• Enough detail to allow the team to estimate, at a high-
level, the size of work to deliver story
• Challenges estimating if...
• The story is too big
• There is insufficient information about the story
• We lack of domain knowledge
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
17. UserINVEST
Stories
Small
• Small enough to be completed in a
TIME
single iteration if possible
• Small for the near future
• Larger stories are okay further out
(Epics)
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
18. UserINVEST
Stories
As a retiree, I want to see a
Testable
summary of my investment accounts
on one screen so that I can decide
• Acceptancecriteria stated in where to focus my attention
customer terms
• Automate whenever possible
• We want to know up front - what
will it take for this to be accepted?
• All investment accounts linked to
the user profileAccount number,
name, total value today displayed
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
19. What to Watch Out For
• Mike Cohn s Catalog of Story Smells
• Stories that are too small
• Stories too big....too many being split later
• Interdependent stories
• Goldplating
• Too much detail
• Interface detail too soon
• Thinking too far ahead
• Lack of customer participation, writing and prioritizing
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
20. Epics
• Epicsare User Stories that cannot be completed in a single
iteration.
• The
larger the User Story, the more unknowns exist and the
more difficult it is for a team to accurately estimate.
• When epics are discovered, teams should work to break the
User Story down to it s smaller components which are then
estimated.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
21. Breaking Down Epics
• Breaking down this epic...
As a student, I want to setup a
product wish list so that my
family can buy me the things
that I want.
• What are some of the ways we could break this down?
Ability to add or remove items Ability to limit access to
s??
selected family members
Ot
Ability to change quantities
her Automatically remove items that
Ability to select occasion for gift have been purchased
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
22. Other Kinds of User Stories
• Systems Stories, Foundational Stories
As the store product
inventory database, I
want hourly updates to
ensure the online store
only displays products in
inventory
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
23. Other Kinds of User Stories: Spikes
SPIKE: As a developer, I want to
research product recommendation
algorithm’s so that we can
intelligently recommend products
based on past purchases.
Spikes do not result in end-user demonstrable
software, therefore every Spike should include
acceptance criteria.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
24. Other Kinds of User Stories
• Constraints[Not truly a user story, should not be sized or
prioritized and should be documented outside of the product
backlog]
As a customer, I want to the
system to offer access from
smart phones so that I don’t
have to be at a computer to
order.
‣ Other types of constraints: performance, design, security,
data handling, and platform.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
25. Things to Remember...
• Write stories that are demonstrable at the end of the iteration
• Decompose larger stories to reduce risk
• Ensurethat you have your product owner s participation in
writing and prioritizing your user stories
• Captureand document spikes, constraints, and system stories
as you discover them
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
26. Your Call To Action
‣ Find experts that can point you
in the right direction if you need
help or guidance. Get training if
you need it.
‣ Share what you learn about the
approach with those teams
around you.
‣ It takes time to get good at
anything, Agile is no exception,
but the rewards are well worth
the effort.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden
27. Your Questions, My Answers
Note: For those questions we do not have time to answer during the webinar,
I will be providing a written response.
Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden