User Stories: Stories for Grown-Ups

8,169 views
8,042 views

Published on

Douglas Talbot & Sandy Mamoli

One of the most fundamental problems facing a project is how you decide on, document, and manage your requirements.

Obviously Agile software development promotes handling this very differently than a Waterfall approach. One mechanism used by Agile projects to track requirements is the "User Story" - but what are they, how are they created, who uses them, when and how, within the development cycle?

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

No Downloads
Views
Total views
8,169
On SlideShare
0
From Embeds
0
Number of Embeds
2,834
Actions
Shares
0
Downloads
271
Comments
0
Likes
13
Embeds 0
No embeds

No notes for slide
  • SANDY Names Cover: Why need user stories, Where they come from, What they look like, What makes a good user story Won’t cover challenges, layers above and below too much (epics, tasks) Co-presenting – differ in details - maybe take a picture for this slide?
  • User Stories: Stories for Grown-Ups

    1. 1. Stories for Grown-ups Inspired by Mike Cohn and Kelly Waters – thank you 
    2. 2. Fixed written requirements
    3. 3. <ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comprehensive documentation </li></ul><ul><li>Customer collaboration over contract negotiation </li></ul><ul><li>Responding to change over following a plan </li></ul>Agile Values
    4. 4. Communications challenge
    5. 5. Collaboration
    6. 6. A continuum
    7. 7. User stories: an improvement
    8. 8. Timeline Epics & Stories Stories & Tasks Stories & Tasks Implemented Stories
    9. 9. Getting to User Stories
    10. 10. Epics <ul><li>Compound epics </li></ul><ul><li>Complex epics </li></ul><ul><li>Placeholder story </li></ul><ul><li>Way down the backlog </li></ul>
    11. 11. Now we can have user stories!
    12. 12. What is a user story? <ul><li>A concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software. </li></ul>
    13. 13. <ul><li>Discovered at planning stages </li></ul><ul><li>Discovered during the project </li></ul><ul><li>Continuously emerge/change and disappear </li></ul><ul><li>For sizing the project and sprint </li></ul><ul><li>For prioritising what to do next </li></ul><ul><li>Monitored each sprint </li></ul><ul><li>For the development team and owner </li></ul>Stories are:
    14. 14. When <ul><li>Some are done at an initial planning stage </li></ul><ul><li>Some are done later </li></ul><ul><li>Continuously emerge/change and disappear </li></ul><ul><li>Worked on throughout the project </li></ul>
    15. 15. Stories are for sizing
    16. 16. Stories are for prioritising
    17. 17. Stories are monitored
    18. 18. Stories are monitored
    19. 19. Stories are monitored
    20. 20. Stories are monitored
    21. 21. Stories are for the team and product owner
    22. 22. Stories have 3 parts <ul><li>Card : A description, Priority and Estimate </li></ul><ul><li>Conversation : A section for capturing further information about the user story and details of conversations </li></ul><ul><li>Confirmation : A section to convey what tests will be carried out to confirm the user story is complete and working as expected </li></ul>Source: XP Magazine 8/30/01, Ron Jeffries.
    23. 23. <ul><li>“ As a music lover </li></ul><ul><li>I want to submit payment by credit card </li></ul><ul><li>so that I can purchase the album ” </li></ul>Card: The Description
    24. 24. Card
    25. 25. Card
    26. 26. A section for capturing further information about the user story and details of conversations The Conversation
    27. 27. A section to convey what tests will be carried out to confirm the user story is complete and working as expected The Confirmation
    28. 28. 6 attributes of a good user story
    29. 29. <ul><li>I ndependent </li></ul><ul><li>N egotiable </li></ul><ul><li>V aluable to users or purchasers </li></ul><ul><li>E stimatable </li></ul><ul><li>S mall </li></ul><ul><li>T estable </li></ul>
    30. 30. Independent
    31. 31. Negotiable
    32. 32. Valuable
    33. 33. Estimatable
    34. 34. Small
    35. 35. Testable
    36. 36. A word of warning <ul><li>Don’t use stories in a sequential fixed process </li></ul><ul><li>Don’t make a contract out of stories </li></ul><ul><li>Don’t write stories in isolation </li></ul>
    37. 37. What next? Challenges Tasks Spikes Feedback
    38. 38. <ul><li>Still alive? Any questions? </li></ul>[email_address] [email_address]
    39. 39. Challenges
    40. 40. Iteration 0
    41. 41. Non-functional requirements
    42. 42. <ul><li>The system will connect to the database through a connection pool </li></ul><ul><li>We need to use Akamai caching </li></ul><ul><li>The system shall be written in Java </li></ul><ul><li>The system needs to be able to store 700 million records </li></ul><ul><li>We need to set up a VISTA development box </li></ul>Customer value?
    43. 43. Spikes

    ×