The document discusses how user stories should follow the INVEST criteria by being independent, negotiable, valuable, estimable, small, and testable. It provides examples of bad user stories that are too large, rely on other stories, contain too many details, and lack acceptance criteria. The document recommends getting users or proxies to write stories, slicing large stories into smaller pieces, focusing on project goals over design, and reviewing stories using INVEST to ensure they are properly defined.

1. Your User Stories Are Bad
And You Should Feel Bad
John Cleary
Lead Web Developer, DocNet
@TheRealBifter
Wednesday, 1 May 13

2. We all know what User
Stories are, right?
Wednesday, 1 May 13

3. As a {user}
I want {some_feature}
so that {i_get_value}
1/3 - THE CARD
Wednesday, 1 May 13

4. The Conversation
with the user
2/3 - THE CONVERSATION
Wednesday, 1 May 13

5. public function theConfirmation()
{
// tests which convey the detail
// and tell us when we are done
}
3/3 - THE CONFIRMATION
Wednesday, 1 May 13

6. The Three Little Pigs
Wednesday, 1 May 13

7. Story:
As a Pig I want a house so that
I am safe and warm
Wednesday, 1 May 13

8. STRAW HOUSE
Wednesday, 1 May 13

9. WOLF ATTACK!
Wednesday, 1 May 13

10. Story:
As a Pig I want a house so that
I am safe and warm
Tests:
Does the structure
withstand strong winds?
Wednesday, 1 May 13

11. WOODEN HOUSE
Wednesday, 1 May 13

12. WOLF ATTACK - AGAIN
Wednesday, 1 May 13

13. Story:
As a Pig I want a house so that
I am safe and warm
Tests:
Does the structure
withstand strong winds of
up to 60mph
Wednesday, 1 May 13

14. BRICK HOUSE
Wednesday, 1 May 13

15. The moral of the story
is...
Wednesday, 1 May 13

16. ... that our user stories
should be ...
Wednesday, 1 May 13

17. Independent
Negotiable
Valuable
Estimable
Small
Testable
Wednesday, 1 May 13

18. Should not rely on other
stories
USER STORIES...
INDEPENDENT
Wednesday, 1 May 13

19. Focus on verbal
communication
USER STORIES...
NEGOTIABLE
Wednesday, 1 May 13

20. “What should I do if my
users stories don’t fit on
the card”
Wednesday, 1 May 13

21. “Use smaller cards”
Wednesday, 1 May 13

22. Should be written from
the user’s perspective
USER STORIES...
VALUABLE
Wednesday, 1 May 13

23. “Implement a centralised
logging system” is
probably not a user story
Wednesday, 1 May 13

24. Must be estimable
USER STORIES...
ESTIMABLE
Wednesday, 1 May 13

25. Need to fit within the
length of the sprint
USER STORIES...
SMALL
Wednesday, 1 May 13

26. Need acceptance
criteria
USER STORIES...
TESTABLE
Wednesday, 1 May 13

27. So, why do my user
stories suck?
Wednesday, 1 May 13

28. They are too small
YOUR STORIES SUCK BECAUSE
© quarksteilchen “Tiny Origami Swan Try 1“ from flikr
Wednesday, 1 May 13

29. They rely on other stories
YOUR STORIES SUCK BECAUSE
© bigoteetoe “Bread & Butter” from flikr
Wednesday, 1 May 13

30. They are just goldplating
YOUR STORIES SUCK BECAUSE
Wednesday, 1 May 13

31. There is too much detail
YOUR STORIES SUCK BECAUSE
© Treefiddy “Grandfather's Watch, B&W“ from flikr
Wednesday, 1 May 13

32. You did too much planning
YOUR STORIES SUCK BECAUSE
Wednesday, 1 May 13

33. You wrote them
YOUR STORIES SUCK BECAUSE
© a2gemma “A Pair Hard At Work“ from flikr
Wednesday, 1 May 13

34. How do I make my
stories less sucky?
Wednesday, 1 May 13

35. 1. Know your users
Wednesday, 1 May 13

36. 2. Get users to write the
stories
Wednesday, 1 May 13

37. 3. Use user proxies if
the user is not available
Wednesday, 1 May 13

38. 4. Run workshops
Wednesday, 1 May 13

39. 5. Have project goals
and sprint goals
Wednesday, 1 May 13

40. 6. If the story is too big
then “slice the cake”
Wednesday, 1 May 13

41. 7. Know what estimates
are for
Wednesday, 1 May 13

42. 8. Postpone design
Wednesday, 1 May 13

43. 9. Accept that not
everything is a story
Wednesday, 1 May 13

44. 10. Review your stories
(using INVEST)
Wednesday, 1 May 13

45. Thank you
John Cleary
Lead Web Developer, DocNet
@TheRealBifter
bit.ly/bad-stories
Wednesday, 1 May 13