1 / 0

Practical User Stories

Practical User Stories. Brett Maytom Senior Consultant, Readify VIC.NET - 10 May 2011. Objective. Introduction Challenges Writing stories INVEST Story lifecycle. What is a story?.

cael
Download Presentation

Practical User Stories

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Practical User Stories

    Brett Maytom Senior Consultant, Readify VIC.NET - 10 May 2011
  2. Objective Introduction Challenges Writing stories INVEST Story lifecycle
  3. What is a story? A concise written description of a piece of functionality that will be valuable to a user (or product owner) of the software.
  4. Purpose Plan work Prioritise Track Build Test Report
  5. Who needs it Product owners Line Managers Program managers Project managers Resource planners Architects Designers Developers Testers
  6. Challenges of weak stories Unclear Ambiguous Different interpretations Epic (too large) Dependencies Importance not understood Team confusion
  7. INVEST (overview) Independent Negotiable Valuable Estimable Small Testable
  8. Story template As a <persona> I would like <some feature> So that <benefit and value>
  9. Persona Define your personas Publish a list of personas Verify story with persona Story must be defined by the persona Think as if you had the role of the persona when working on the story Persona will accept story as “done”
  10. Feature Describe the feature needed Word it for the product owner and persona Avoid geek speak One feature per story If you cant describe it on one card, then it is probably too big
  11. Benefit Adds additional clarity to feature Vital for product owners Why should the product owner spend money to build this feature? Justify the prioritisation
  12. Acceptance Criteria Given \ When \ Then If there are too many, it is possible the story should be split into multiple stories Risks, Issues, Concerns Identify need for spikes Identifies uncertainty Dependencies
  13. Who is responsible for the story? Product owner Business Analyst (Proxy)
  14. Story inputs
  15. Independent Do not overlap Are not dependant on order Delivered in any order
  16. Negotiable “Promise to communicate” Not an explicit contract Created by product owner and team Captures the essence of work Morphs as understanding improves Does not have to be fully complete
  17. Cone of uncertainty
  18. Story Lifecycle
  19. Valuable Valuable to product owner Technical stories framed in a way that adds value to customer perspective Split vertical No Frameworks Think ROI
  20. Estimable Not exact Help product owner rank and schedule Sizing to identify big stories Spike new and unknown technologies Team needs to mature over time
  21. Small Small enough to complete in a single iteration Kept to 2-3 days for done-done Don’t go to task detail Big stories indicate lack of detailed understanding
  22. Testable Defines what the product owner will agree to be complete This is “the contract” Involve testers early
  23. Recommendations Constantly inspect, adapt and evolve Clear and explicit Communicate Multiple people need to be involved Constantly work on the stories
  24. Thank you Brett Maytom brett.maytom@readify.net http://brett.maytom.net
More Related