The document provides guidance on how to effectively write and use user stories in Agile software development. It discusses key principles such as writing user stories from the perspective of the end user to ensure they provide business value. The document also covers best practices for user stories, such as making them independent, negotiable, estimable, and testable. Tips are provided on properly sizing user stories and determining acceptance criteria to know when a story is complete. Common anti-patterns for user stories are also identified.

1. How do you get
more out of
your user stories?

2. Let’s first
refresh our basics
© 2013

3. Key Agile
principles
!
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
!
We welcome changing requirements, even late in development.
!
Business and IT teams must work together.
http://www.agilemanifesto.org/principles.html
© 2013

4. What is a
user story?
= Card + Conversation + Confirmation
© 2013

5. Card
What is a
user story?
#32
As a use
r
I want t
o do som
ething
so that s
ome bene
fit is
received
! Physical token
! Used in planning
! Reminder for a conversation
! Often annotated
© 2013

6. Conversation
What is a
user story?
! Requirement itself
! Verbal conversation / workshops
! Supplemented with documents / wireframes / mocks
© 2013

7. Confirmation
What is a
user story?
#32
Given <
precondi
tions>
When <t
rigger>
Then <e
xpected
outcomes
>
! Acceptance criteria
! Used to determine when the story is done
© 2013

8. Now, let’s see what makes a
good user story?
© 2013

9. What makes a
good user story?
The INVEST guideline for writing a good story
Independent
Negotiable
Valuable
Estimable
Small
Testable
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
© 2013

10. What makes a
good user story?
Pay by Visa
Pay by MasterCard
Independent
Negotiable
Pay by AmEx
Pay by Credit Card
Valuable
Estimable
Small
þ Do not overlap your stories in concept.
þ When sequencing the stories, try to find their natural order.
Testable
The order of stories should not restrict your customer’s ability to reprioritize or move stories out of scope.
© 2013

11. What makes a
good user story?
Independent
Negotiable
Valuable
As a purchaser, I want th
e receipt to display the da
te
of my purchase in ISO 86
01 format Comic Sans 12
pt
font with 9pt leading, so
that I can maintain my
records.
hen I
to indicate w
e receipt
tain my
aser, I want th
at I can main
As a purch
ase, so th
ted the purch
comple
records.
Estimable
þ Stories are negotiable...and negotiated.
þ Remember, your story is the essence of the requirement and not an explicit
Small
þ Sign off stories with working software.
contract.
Testable
Avoid signing off written stories before they are played, as it creates
contractual documents that shift the focus to documentation.
© 2013

12. What makes a
good user story?
Independent
Negotiable
Valuable
Estimable
Small
Testable
As a developer/DBA
, I want a new table
in the
Orders DB to capture
shipping informatio
n, so
that ???
eferred
cify my pr
e to spe
ther
t to be abl
address o
wan
m er , I
ip to an
As a custo
at I can sh
ls, so th
ping detai
ship
dress
y billing ad
than m
þ Your stories need to be valuable to and understandable by your customer.
þ They need to be framed from your customer’s perspective.
If it is difficult to write the "so that....” part easilyyou might want to consider the
story’s value and purpose.
Avoid layer-based development. Instead choose vertical slices of functionality.
Technical debt are not user stories.
© 2013

13. What makes a
good user story?
Independent
Negotiable
As a good world citize
n, I want world peace
,
so that we can all live
in harmony.
aypa
o pay by P
able t
want to be
goer, I
card.
s a movie
my credit
A
to use
don’t have
that I
l, so
Valuable
þ Your stories should have boundaries so you know when you are “done” and
Estimable
þ Your stories should be digestible by the team so they can estimate them.
þ Keep your stories understandable and of consistent granularity.
þ “Spike” stories that your team has difficulty understanding.
Small
what is required to be “done”.
Testable
Avoid “catch-all” stories with uncertain estimates.
Don’t get bogged with precision and detail.
© 2013

14. What makes a
good user story?
Independent
Negotiable
Valuable
Estimable
Small
As a movie goer, I wa
nt to be able to find
and
purchase movie tick
ets online, so that I h
ave
something to do ton
ight.
le,
ovie by tit
nd a m
e able to fi a movie I am
ant to b
tails of
e goer, I w
s a movi
ate the de
A
ckly loc
t I can qui
s o t ha
in.
interested
þ Keep your stories small enough to be measured and tracked.
þ Keep your story descriptions short and concise.
Testable
Stories should be measured in days not weeks.
© 2013

15. What makes a
good user story?
Improve readability
lete term
placed with comp
All acronyms re
Independent
Negotiable
inology
A user must never have to wait long for a screen to appear
New screens appear within 2 seconds 95% of time
Valuable
Estimable
Small
þ To know when your story is done, it needs to be testable.
þ Define acceptance criteria that are clear and precise so you know when you are
done and have delivered value.
Testable
First define your tests and then develop.
© 2013

16. How do you
size your stories?
© 2013

17. How do you
size your stories?
Advantages of larger stories
Larger
Vs.
Smaller
No ‘challenge’ of splitting
Perceived ‘efficiencies’
Clearer business value
Easier to prioritize
Advantages of smaller stories
Accurate estimates
Finding t
he
right sto
ry size
can be h
ard
Planning flexibility
Measure of progress
Understanding of scope
© 2013

18. How do you
size your stories?
§
§
§
§
Agree on target story size with the development team.
The exercise is a joint effort with the customer and the development team.
Don’t break down stories too soon - progressively elaborate.
Use story complexity, operational (eg. CRUD) and data boundaries as guides.
Breaking down
stories
© 2013

19. How do you know when
your story is done?
© 2013

20. How do you know
when your story
is done?
Tips for writing
acceptance criteria
Given <
some in
itial con
text>
when <a
n event
occurs>
then <en
s
ure som
e outcom
es>
þ Define “complete” with the customer
þ Write acceptance criteria collaboratively with the customer
þ All the criteria must be met before the story is “complete”
þ Consider using a template
þ Include all Risks, Assumptions, Issues and Dependencies (RAID)
© 2013

21. How do you know
when your story
is done?
Smart
Be smart with
Measurable Possible to observe and quantify
acceptance criteria
Achievable
Capable of existing or taking place
Relevant
Having a connection
Timely
When will the outcome be observed?
Explicitly defined and definite
© 2013

22. Lifecycle of a story
© 2013

23. Lifecycle of a story
“
The fundamental idea is that you do just barely enough
modelling at the beginning of the project to understand the
requirements for your system at a high level, then you gather
the details as you need to…just-in-time.
*
*
*
-- Scott W. Ambler
Why “just-‐in-‐time”?
§
§
§
§
Reduces potential waste.
Provides flexibility to change, prioritize.
Enables learning from delivery.
Tighter feedback loop between business and the delivery team.
© 2013
”

24. Lifecycle of a story
#1. Start at the
Product Level
! Develop an understanding of the breadth
§ Objectives/vision statements
§ Elevator pitch
§ Product box
§ User roles & goals
§ Context diagrams
§ High-level domain model
§ Feature lists
§ Paper prototypes
§ …
Product Families
Themes
Feature Sets
Features / Epics
Stories
© 2013

25. Lifecycle of a story
#1. Start at the
Product Level
#2. Examine the
Release Level
! Take a closer look at a subset of features:
§ Data models
§ Business needs
§ Architectural dependencies
§ Quality attributes (Non-Functional
Requirements)
§ Personas/actors
§ Define epics
§ More paper prototyping
§ …
Product Families
Themes
Feature Sets
Features / Epics
Stories
© 2013

26. Lifecycle of a story
#1. Start at the
Product Level
#2. Examine the
Release Level
#3. Deep-dive into the
Iteration Level
! Go deep, but focusing just on one thin slice
§ User stories
§ Narratives
§ Acceptance criteria and tests
§ Working software
§ Involve Subject Matter Experts
and Stakeholders
§ User and exploratory testing
§ …
Product Families
Themes
Feature Sets
Features / Epics
Stories
© 2013

27. Non-functional
requirements
© 2013

28. Non-functional
requirements as…
Acceptance Criteria
As a customer, I want to be able to pay by
PayPal, so that I can complete my
purchase.
[Acceptance Criteria]
- payment confirmed within 5 seconds
- handle 100 concurrent payments
- encrypted redirect to PayPal
…
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
© 2013

29. Non-functional
requirements as…
Acceptance Criteria
As a developer, I want all connections to
the database to be made through a
connection pool, so that ???
Separate User Stories
As a CTO, I want up to 50 users to be
able to use the application with a fiveuser database license, so that I can
minimize ongoing license costs.
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
© 2013

30. Non-functional
requirements as…
Acceptance Criteria
[CONSTRAINT]
Separate User Stories
As the CTO, I want the system to use our existing
Constraint Cards
orders database rather than create a new one,
so that we don’t have one more database to
maintain.
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
© 2013

31. Story Anti-patterns
© 2013

32. Story Anti-patterns
§ Is there any reference to business value?
§ Is your story too detailed. Is it “replacing” the conversation?
Look out for these
smells...
§ Do you have trouble prioritizing it?
§ Is it too small or too big to estimate?
§ Does it have implementation details and technical language?
§ Are you thinking *too* far ahead?
§ Is the product owner unable to explain the card to you?
§ Are you splitting it by process lines (analysis/code/test)?
§ Gold-plating?
© 2013

33. Back to our basics
© 2013

34. Key Agile
principles
!
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
!
We welcome changing requirements, even late in development.
!
Business and IT teams must work together.
© 2013

35. §
Cohn, Mike
§
§
References
(2004) "User Stories Applied”, Addison Wesley, ISBN 0-321-20568Non-functional requirements
http://www.mountaingoatsoftware.com/blog/non-functionalrequirements-as-user-stories
§
Sutherland, J (2007) User Stories Done Right
http://www.gbcacm.org/sites/www.gbcacm.org/files/slides/4A%20-%20User
%20Stories%20Done%20Right.pdf
§
Wake, B (2003) INVEST acronym
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
§
Meyer, Paul J (2003) SMART acronym
"What would you do if you knew you couldn’t fail? Creating S.M.A.R.T. Goals".
Attitude Is Everything: If You Want to Succeed Above and Beyond. Meyer Resource
Group, Incorporated, The. ISBN 978-0-89811-304-4.
§
Jeffries, Ron (2001) Card, Conversation, Confirmation
http://xprogramming.com/articles/expcardconversationconfirmation/
§
Lawrence, R (2009) Patterns for Splitting User Stories
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
© 2013

36. How do you get the most out of
your user stories?
© 2013

37. Agile Project Management
Make decisions, not documentation
The best Agile requirements are the ones the
team builds as they work. Mingle generates
actionable project records from natural team
collaboration.
Learn More
See how Mingle can help you make the most
out of your user stories