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.
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
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”)
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
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
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
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
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