"How to write better User Stories" por @jrhuerta
•
1 recomendación•882 vistas
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.
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a "How to write better User Stories" por @jrhuerta
Similar a "How to write better User Stories" por @jrhuerta (20)
Más de webcat
Más de webcat (20)
Último
Último (20)
"How to write better User Stories" por @jrhuerta
- 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
- 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