User Stories

  • 4,454 views
Uploaded on

This presentation provides the who, what, why, how, and when for user stories. It shows you examples of good and bad stories, how to get them in the first place, and how they define done on agile …

This presentation provides the who, what, why, how, and when for user stories. It shows you examples of good and bad stories, how to get them in the first place, and how they define done on agile projects.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
4,454
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
1
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. User Stories
    • Robert Dempsey
  • 2. Robert Dempsey
    • CEO of Atlantic Dominion Solutions
    • Certified ScrumMaster
    • Developer
    • Student
    • Husband and Father
  • 3. User Stories: A First Glance
  • 4. “ represent customer requirements rather than document them.” - Rachel Davies “reminders to have a conversation rather than fully detailed requirements” - Mike Cohn
  • 5. What’s in a story?
    • Written description of the story
    • Conversations that provide details
    • Tests that define “done”
  • 6. A Good Example
    • A user can add his picture to his profile.
  • 7. A Bad Example
    • The application will be built using Java.
  • 8. Where’s the beef?
    • Write more user stories
    • 1/2 day to 2 weeks coding/testing for 1-2 developers
    • Stay away from epics
  • 9. Our Social Network
    • A user can manage his profile
    • A user can connect with other users
  • 10. “ ...connect with other users”
    • A user can create a group
    • A user can friend other users
    • A user can start discussions
  • 11. Break em’ down, but...
    • Don’t get too detailed
    • A user can create a group
      • A group can have a name
      • A group can have a description
      • A group can have members
  • 12. Who say’s I’m done?
    • Acceptance criteria
      • Test with a blank name
      • Test with names of varying lengths
      • Test with adding a picture
  • 13. Where do they come from?
    • The customer writes the user stories
    • Story writing workshops
    • Written at any time during the project
  • 14. Where do they go?
    • Releases
      • Iterations
        • User Stories
  • 15. And why do I want these?
    • Emphasize verbal communication
    • Understood by suits and techies
    • Defers decisions and details
    • Work with iterative development
  • 16. Spinning Tales
  • 17. INVEST in your stories
    • Independent
    • Negotiable
    • Valuable to users or customers
    • Estimatable
    • Small
    • Testable
    * Extreme programming and Refactoring workbook , BILL WAKE (2003)
  • 18. Independent
    • Avoid dependencies
      • Combine stories
      • Split the stories differently
  • 19. Negotiable
    • Stories are not written contracts
    • Just the right amount of detail
    • Pick up the conversation where it left off
    • Details become tests
  • 20. Valuable
    • Users vs. Purchasers
    • Avoid stories that
      • Only developers value
      • Focus on technologies
      • Contain UI assumptions
    • Customers write user stories
  • 21. Estimatable
    • Roadblocks
      • Lack of domain knowledge
      • Lack of technical knowledge
      • Epics
    • Spike
      • Time-boxed story for researching
  • 22. Small
    • “ Story size does matter.”
    • Split the biggies (epics)
      • Compound vs. Complex
      • Put the spike to a separate iteration
    • Combine the smallies
  • 23. Testable
    • Tests define done
    • Nonfunctional requirements lead to untestable stories
    • Automate your tests
    • Not all tests can be automated
  • 24. Modeling (User Roles)
  • 25. Who wants some?
    • User role
      • “ Collection of defining attributes that characterize a population of users and their intended interactions with the system.”
  • 26. Examples
    • Software developer
    • Designer
    • Marketer
    • Recruiter
  • 27. Modeling Process
    • Brainstorm
    • Organize
    • Consolidate
    • Refine
  • 28. Organize Undergrad Senior developer Junior developer UI designer DB Admin Monitor Marketer Recruiter Networker Admin
  • 29. Consolidate Member External Recruiter Recruiter Internal Recruiter Admin Senior developer Junior developer UI designer DB Admin
  • 30. Refine User Role: Recruiter Not very tech-saavy but highly adept at using the Web for research. Will mainly use the site to search for potential job candidates.
  • 31. Hunt and Gather
  • 32. Gathering Techniques
    • User interviews*
    • Questionnaires
    • Observation
    • Story-writing workshops
  • 33. Prototype Home Page Latest Activity Members Forum Sign up Signup fields User Login Account info Search Members Search fields Forums List forums Search Results List of matching members Post Events Event fields
  • 34. User Stories
    • A Recruiter can search for members
    • A Recruiter can view results of a member search
    • A Member can post to the forums
    • A Member can create an event
  • 35. User Proxies
  • 36. User Proxies
    • The users’ manager
    • A development manager
    • Salespersons
    • Domain experts
    • The marketing group
    • Former users
    • Customers
    • Trainers and tech support
    • Business/Systems analysts
  • 37. Acceptance Tests
  • 38. Acceptance Testing
    • Details = tests
    • Write tests before coding
    • Have the customer write the tests
    • Tests should add value and clarification
    • Automate, automate, automate
    • UI, usability, performance, stress
  • 39. Guidelines
  • 40. Guidelines
    • Start with goal stories
    • Slice the cake
    • Write closed stories
    • Put constraints on cards
    • Size the story to the horizon
    • Keep the UI out as long as possible
    • Some things aren’t stories
    *User stories applied for agile software development , MIKE COHN (2004)
  • 41. Guidelines
    • Include user roles in the stories
    • Write for one user
    • Write in active voice
    • Customer writes
    • Don’t number story cards
    • Don’t forget the purpose
    *User stories applied for agile software development , MIKE COHN (2004)
  • 42. Resources
  • 43. Resources
    • Story Writing Workshop: agiledevelopmentwithscrum.com
  • 44. Contact Rob
    • http://adsdevshop.com
    • http://blog.adsdevshop.com
    • http://twitter.com/rdempsey
    • http://linkedin.com/in/robertwdempsey
    • http://agiledevelopmentwithscrum.com
  • 45. Thank you