"How to write better User Stories" por @jrhuerta

700 views

Published on

Presentación realizada en el #webcat Barcelona de Abril 2013

Autor: José E. Rodríguez (@jrhuerta)

------------------------------------------------
RECURSOS:

- Agile Barcelona
http://agile-barcelona.org/

- "User Stories Applied: For Agile Software Development", Mike Cohn, 2004, Addison-Wesley Professional
http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685

- "Lean UX", Jeff Gothelf & Josh Seiden, 2012, O'Reilly Media
http://www.leanuxbook.com/

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
700
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

"How to write better User Stories" por @jrhuerta

  1. 1. Writing better userstoriesJosé E. Rodríguez Huerta(@jrhuerta)
  2. 2. DisclaimerNot a single originalthought in thispresentation.Although there is some first handexperience
  3. 3. What this talk is about•  Why use user stories at all?•  Some guidelines on how toimprove•  Identifying common “userstory smells…”
  4. 4. Why use User storiesat all?
  5. 5. Requirements gathering is anintegral part of softwaredevelopment
  6. 6. Common pitfalls•  Lack of context•  Fail to deliver value•  Overly specified•  User/Client doesnt knowwhat 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 theusers are and what theyexpect from the software.•  Long feedback loopsfrom users/stakeholders•  Acceptance criteria is:everything is implemented.•  Hard to maintain
  7. 7. User stories to the rescue!
  8. 8. Yes, they are still arequirements document,but…
  9. 9. They are cool
  10. 10. How do User Storiesaddress those problems?•  Provide Context =>Aligment•  End user/customerlanguage, makes it easyto read/understandbridges the gap betweentechnical and business•  Focus on Delivering Value•  User/Customer centered•  Small, Cheap•  Easily priorizable and re-priorizable•  Versatile•  Switch the focus tocommunication instead ofa detailed specification.•  Shortens Time to Market.
  11. 11. What is a user story?three critical parts:– Card– Conversation– Confirmation(“conversation placeholders”)
  12. 12. What isa “Good” USER STORY?  
  13. 13. It helps YOUto solve your problem
  14. 14. Defining a “good” u.s.•  follows the INVEST acronym(by Bill Wake)•  Defines conditions FOR“satisfaction” (in DoD)•  Defines conditions FOR“readyness” (in DoR)
  15. 15. Defining a “good” U.S.•  Uses the customer’s language•  has the Who, the What and Why•  Everyone participates indefining/refining
  16. 16. I.N.V.E.S.T.•  Independent•  Negotiable•  Value•  Estimable•  Size/Small•  Testable
  17. 17. I for IndependentIndependent also means it canbe built incrementalyand iteratively
  18. 18. IncrementalArt  by  Jeff  Pa,on  
  19. 19. IterativeArt  by  Jeff    Pa,on  
  20. 20. Incremental-InterativeArt  by  Steven  Thomas  
  21. 21. I for IndependentOk… maybe, some dependency
  22. 22. N for Negotiable•  Avoid implementation details– It says the What, not the How.•  Its not carved in stone– Until its part of an iteration itcan still be rewritten
  23. 23. V for ValueProvide value to your customerwith every story
  24. 24. V for Value
  25. 25. V for Value
  26. 26. V for Value
  27. 27. E for EstimableOtherwise you can’t know when itwill be done(or if it will ever be…)
  28. 28. S for Size/Small•  If its too big, split it.–  Learn how.•  If it too small, maybe its not auser story–  I smell micromanagement!
  29. 29. T for TestableIf it’s not worth testing it…Is it worth writting it?
  30. 30. Not everything is aUser Story
  31. 31. What?•  The process context:–  Definition of Done–  Definition of Ready•  Non functional requirements:–  Requirements that extendthrough the whole project
  32. 32. Use aids to “Power Up”•  Wireframes•  Navigation maps•  Color tags•  Personas•  User Story maps•  Anything else you may finduseful
  33. 33. Use aids to “Power Up”•  Wireframes•  Navigation maps•  Color tags•  Personas•  User Story maps•  Anything else you may find useful
  34. 34. Revise and Refine and evenRe-do•  User stories are alive, they:–  Are Born–  Grow–  Reproduce–  Die•  Make time to groom yourbacklog with the team and client
  35. 35. user story smells
  36. 36. User Story smells…•  Too much detail or too little detail•  No conditions of satisfaction•  A story per page/component orsliced in ways that don’t deliver value•  Technical tasks masqueraded as userstories•  Skipping the conversation
  37. 37. 15m is not a lot of timeso…
  38. 38. Where DO I get more info?•  Agile Barcelona community (@agilebcn)•  Books:–  User stories applied: For Agile SoftwareDevelopment by Mike Cohn–  Lean UX: Applying Lean Principles to ImproveUser Experience by Jeff Gothelf & Josh Seiden•  The Mountain Goat Software:http://www.mountaingoatsoftware.com/•  Google
  39. 39.  ThanksAny questions?(@jrhuerta)

×