This document discusses improving user stories by following best practices like the INVEST acronym. It explains that user stories address common requirements gathering pitfalls by focusing on delivering value to end users, using their language, and enabling prioritization and incremental development. The document provides guidelines for writing "good" user stories, including having context, value, and acceptance criteria, as well as being independent, negotiable, estimable, small in size, and testable. It also identifies potential "user story smells" to avoid.

1. Writing better user
stories
José E. Rodríguez Huerta
(@jrhuerta)

2. Disclaimer
Not a single original
thought in this
presentation.
Although there is some first hand
experience

3. What this talk is about
• Why use user stories at all?
• Some guidelines on how to
improve
• Identifying common “user
story smells…”

4. Why use User stories
at all?

5. Requirements gathering is an
integral part of software
development

8. Common pitfalls
• Lack of context
• Fail to deliver value
• Overly specified
• User/Client doesnt know
what they want.
• No priorization
• Hard to build incrementaly
• Difficult to estimate
• Too long… Didn’t read.
• Too technical… Didn’t read.
• Long time to market cycle
• Not always clear who the
users are and what they
expect from the software.
• Long feedback loops
from users/stakeholders
• Acceptance criteria is:
everything is implemented.
• Hard to maintain

9. User stories to the rescue!

10. Yes, they are still a
requirements document,
but…

11. They are cool

12. How do User Stories
address those problems?
• Provide Context =>
Aligment
• End user/customer
language, makes it easy
to read/understand
bridges the gap between
technical and business
• Focus on Delivering Value
• User/Customer centered
• Small, Cheap
• Easily priorizable and re-
priorizable
• Versatile
• Switch the focus to
communication instead of
a detailed specification.
• Shortens Time to Market.

13. What is a user story?
three critical parts:
– Card
– Conversation
– Confirmation
(“conversation placeholders”)

14. What is
a “Good” USER STORY?

15. It helps YOU
to solve your problem

16. Defining a “good” u.s.
• follows the INVEST acronym
(by Bill Wake)
• Defines conditions FOR
“satisfaction” (in DoD)
• Defines conditions FOR
“readyness” (in DoR)

17. Defining a “good” U.S.
• Uses the customer’s language
• has the Who, the What and Why
• Everyone participates in
defining/refining

18. I.N.V.E.S.T.
• Independent
• Negotiable
• Value
• Estimable
• Size/Small
• Testable

19. I for Independent
Independent also means it can
be built incrementaly
and iteratively

20. Incremental
Art
by
Jeff
Pa,on

21. Iterative
Art
by
Jeff
Pa,on

22. Incremental-Interative
Art
by
Steven
Thomas

23. I for Independent
Ok… maybe, some dependency

24. N for Negotiable
• Avoid implementation details
– It says the What, not the How.
• Its not carved in stone
– Until its part of an iteration it
can still be rewritten

25. V for Value
Provide value to your customer
with every story

26. V for Value

27. V for Value

28. V for Value

29. E for Estimable
Otherwise you can’t know when it
will be done
(or if it will ever be…)

30. S for Size/Small
• If its too big, split it.
– Learn how.
• If it too small, maybe its not a
user story
– I smell micromanagement!

31. T for Testable
If it’s not worth testing it…
Is it worth writting it?

32. Not everything is a
User Story

34. What?
• The process context:
– Definition of Done
– Definition of Ready
• Non functional requirements:
– Requirements that extend
through the whole project

35. Use aids to “Power Up”
• Wireframes
• Navigation maps
• Color tags
• Personas
• User Story maps
• Anything else you may find
useful

36. Use aids to “Power Up”
• Wireframes
• Navigation maps
• Color tags
• Personas
• User Story maps
• Anything else you may find useful

37. Revise and Refine and even
Re-do
• User stories are alive, they:
– Are Born
– Grow
– Reproduce
– Die
• Make time to groom your
backlog with the team and client

38. user story smells

39. User Story smells…
• Too much detail or too little detail
• No conditions of satisfaction
• A story per page/component or
sliced in ways that don’t deliver value
• Technical tasks masqueraded as user
stories
• Skipping the conversation

40. 15m is not a lot of time
so…

41. Where DO I get more info?
• Agile Barcelona community (@agilebcn)
• Books:
– User stories applied: For Agile Software
Development by Mike Cohn
– Lean UX: Applying Lean Principles to Improve
User Experience by Jeff Gothelf & Josh Seiden
• The Mountain Goat Software:
http://www.mountaingoatsoftware.com/
• Google

42.
Thanks
Any questions?
(@jrhuerta)