The document discusses user stories and provides guidelines for writing good user stories according to the INVEST criteria. User stories should be independent, negotiable, valuable, estimable, the right size, and testable. They describe the goal a user wants to achieve and the value of that goal. User stories help define a project's requirements and align closely with feature descriptions.

1. INVEST in good user stories

2. Our project defines it’s requirements as User Stories

3. A user story is a description of what goals a user wants to achieve in the system

4. User stories are closely aligned to feature descriptions

5. User stories highlight the role of the user

6. The goal they are trying to achieve

7. And the value of that goal

8. As a <user type> I want to <achieve a goal> So that I can <get some value>

9. For more information there are references at the end of this presentation

10. There are good and bad user stories out there.

11. In the tradition of S.M.A.R.T. goals, Bill Wake advises us to I.N.V.E.S.T. in user stories

12. INVEST I ndependent N egotiable V aluable E stimable S ized right T estable

13. Avoid dependencies on other stories Write stories to establish the system foundation Combine stories for a single iteration (where appropriate) Independent Negotiable Valuable Estimable Sized right Testable

14. Stories are not a contract Too much written detail – it suggests that there is no more to explore Know when you can’t negotiate – some constraints are fixed Independent Negotiable Valuable Estimable Sized right Testable

15. Show what the value of the story is for the customers and other stakeholders Independent Negotiable Valuable Estimable Sized right Testable

16. Sufficient detail needs to be present to estimate the work effort Stories should be small enough to estimate, (but not too small) Independent Negotiable Valuable Estimable Sized right Testable

17. Stories should be small enough to complete in a sprint (2 weeks) The closer a story is to being worked on the more specific it should be Stories can start high level (epic) but they’ll need to be broken down later Independent Negotiable Valuable Estimable Sized right Testable

18. Acceptance criteria should be apparent in the user story Tests should be automated wherever possible User stories should not be commenced until they have clear acceptance criteria Independent Negotiable Valuable Estimable Sized right Testable

19. References Extreme Programming Explored - William Wake http://www.scribd.com/doc/12720/Extreme-Programming-Explored-William-Wake Six features of a good user story http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest INVEST in Good Stories, and SMART Tasks http://xp123.com/xplor/xp0308/index.shtml XP Practice: stories http://agilesoftwaredevelopment.com/xp/practices/stories User stories (in general) http://agilesoftwaredevelopment.com/taxonomy/term/170/0