View
111
Download
2
Category
Tags:
Preview:
DESCRIPTION
Citation preview
Writing better user stories
José E. Rodríguez Huerta (@jrhuerta)
Disclaimer
Not a single original thought in this presentation.
Although there is some first hand
experience
What this talk is about
• Why use user stories at all?
• Some guidelines on how to
improve
• Identifying common “user
story smells…”
Why use User stories at all?
Requirements gathering is an
integral part of software
development
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
User stories to the rescue!
Yes, they are still a
requirements document,
but…
They are cool
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.
What is a user story?
three critical parts:
– Card
– Conversation
– Confirmation
(“conversation placeholders”)
What is a “Good” USER STORY?
It helps YOU
to solve your problem
Defining a “good” u.s.
• follows the INVEST acronym
(by Bill Wake)
• Defines conditions FOR
“satisfaction” (in DoD)
• Defines conditions FOR
“readyness” (in DoR)
Defining a “good” U.S.
• Uses the customer’s language
• has the Who, the What and Why
• Everyone participates in
defining/refining
I.N.V.E.S.T.
• Independent
• Negotiable
• Value
• Estimable
• Size/Small
• Testable
I for Independent
Independent also means it can
be built incrementaly
and iteratively
Incremental
Art by Jeff Pa,on
Iterative
Art by Jeff Pa,on
Incremental-Interative
Art by Steven Thomas
I for Independent
Ok… maybe, some dependency
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
V for Value
Provide value to your customer with every story
V for Value
V for Value
V for Value
E for Estimable
Otherwise you can’t know when it will be done
(or if it will ever be…)
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!
T for Testable
If it’s not worth testing it… Is it worth writting it?
Not everything is a
User Story
What? • The process context:
– Definition of Done
– Definition of Ready
• Non functional requirements:
– Requirements that extend
through the whole project
Use aids to “Power Up”
• Wireframes
• Navigation maps • Color tags • Personas • User Story maps • Anything else you may find
useful
Use aids to “Power Up”
• Wireframes
• Navigation maps
• Color tags
• Personas
• User Story maps
• Anything else you may find useful
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
user story smells
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
15m is not a lot of time so…
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/
Thanks Any questions?
(@jrhuerta)
Recommended