User stories primer - how to think differently about constructing stories
•Télécharger en tant que PPTX, PDF•
0 j'aime•1,375 vues
Writing user stories is more than just changing the format of the requirements. Think differently about the product and the user and keep ideas simple and independent.
Recommandé
Recommandé
Contenu connexe
Similaire à User stories primer - how to think differently about constructing stories
Similaire à User stories primer - how to think differently about constructing stories (20)
Plus de Dave Ungar
Plus de Dave Ungar (9)
Dernier
Dernier (20)
User stories primer - how to think differently about constructing stories
- 1. In this session we’ll talk mainly about user stories and not the overall methodology. Some of that will creep in along the way, but we won’t focus on it. All you really need to know about agile for today is: Communicate more, Cut out waste by questioning the process, and work in smaller increments.
- 3. what is a user story: a high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. Typical formats As a, I want to because As a temporary library employee, I want to check in these books, so they can be reshelved. Given, when, then – enables more contexts (givens) & outcomes (thens.) Given that I am new here, when a patron returns a book, then enable me to check it in and tell me where it goes. Remember Personas – think about the motivation of the subject of the story. E.g. "As a library patron, I want to log in because ….. why?" A user doesn't want to log in ever. The story may be "As the system owner, I want users to log in so we can ensure proper authorization / use of our data/ system /// .. " Or what else? WHY do we want people to log in? be clear about it.
- 4. •How user stories are different from requirements - The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. Focus on user needs. Avoid details of specific technology, data base layout, and algorithms. •How user stories are different from Use Cases – What the user wants to do versus specific ways in which the user may do it. ** User stories should typically address only ONE, happy-path scenario for how the system will be used. ***Details usually found in a use case should not be part of the user story. User stories should be one sentence. (Use cases or other dialog about specific use/intention comes later, during development – as a conversation.) •What is acceptance criteria? - define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. Essentially – what grade/level of quality is acceptable for the story? (e.g. is a confirmation necessary? Is data validated before saving? Don't just state the story in reverse. "As a patron, I want to find a book in your library." Acceptance: (perhaps) Tell user whether or not we own the book. Tell user whether the book is available. Tell user shelving location. Tell user about other formats.)
- 5. Iterative Design & Refactoring > We don’t want to end up with this… … nor design for this….
- 6. User Story: Just get across the chasm - To find out if that’s the place we want to go One person at a time Build in flexibility: >NOT so you can add specific features later >But so you can address UNKNOWN change with minimal impact Build in Quality: >Appropriate architecture and completeness ONLY for the requirements given. >Quality – make sure the rope isn’t frayed and is tied tightly
- 7. User Story: Just get across the chasm - To find out if that’s the place we want to go One person at a time The best way to build in flexibility and quality is to remain SIMPLE as long as possible. You *might* assume that the bridge will need to be bigger/ heartier in time .. but the requirement TODAY is to get one person across. Will you still use the wire when this becomes a highway bridge? Probably not – but don't sink enormous pilings to string up a wire just because it'll probably need to be replaced in the future. Today, just get it across as quickly and cheaply as possible – BUT, make sure the structure is sound & safe to use. (i.e. use appropriate architecture that will be easy to modify IF needed.)
- 8. Story: I want to get there faster and with less effort Design a pulley system Quality - Can it still hold the weight? Do the pulleys turn freely? Negotiable quality – is there a secondary safety line? Should the rider have a helmet?
- 9. Story: More stable & user friendly Holds more weight Most people can get across Quality: strong lashings. (NOT easily removed later when if you want to upgrade the bridge!)
- 10. Story: More durable – more traffic Holds more weight Average vehicles can get across Quality: Solid architecture to hold a car, but not meant to hold two cars or support high speed traffic. >Rope bridge is a sunk cost. >How much will it cost to refactor the rope bridge? >Is it worth it?
- 11. Story: More scalable – able to support a tank … Holds more weight Any vehicle can get across, many at once Quality: This is the mature product that meets the vision. ..until ……
- 12. Story: Support ancillary value propositions Quality: Is the existing structure capable of supporting additional functions? Or is it a significant change that requires cost justification?
- 13. Business Drivers Categories Workflow Efficiency Sell/Implement Sooner/ Faster Basic/Core Sell More Exciters Reuse Data Sustained Growth & Reduce Cost Nonfunctional Record Quality Process Faster System Stability & Security System Scalability SuperEpics Integrate other tools Less reliance on experts Import Export QA new records Fix existing records Macros and templates Batch operations Security Improve Performance Measure Performance
- 14. INVEST Independent Negotiable Valuable Estimable Small Testable A few good practices: •INVEST •Keep stories small , do the simplest thing possible •Keep stories singular - no 'if/else' or 'what if' conditions (Use cases –vs- user stories.) "I want to borrow a book." .. Assume the book is available. have $600 in fines, … Refactoring: In order to add these requirements later, we'll have to create stories & develop them – LATER. Will that mean rework? Probab that's OK. Costs less to rework later than to develop functionality that won't be used or will delay release. When you do refactor: 1) Do it r requirements in front of you. 2) Assess the cost of adding the requirement – do you really want it?
- 15. Early stories – focus on delivering value – get the product right first & focus on the inner workings after getting some user feedback. “Go ugly, early.”
- 16. Exercise – write user stories for : creating a vending machine for drinks Start with the basic story: As a thirsty person, I want to buy a drink from your vending machine What would the acceptance be? Remember – thin slices and do the simplest thing.:Machine will take my money Machine will have a drink selection mechanism (eg select product by position on shelf, or by drink name, etc) Machine will deliver drink Negotiable criteria: (Maybe these are specified or maybe they are not required to address yet.) Will give me change back Won't take money if sold out Won't let me get two drinks, ensures I paid first, ...
Notes de l'éditeur
- In this session we’ll talk mainly about user stories and not the overall methodology. Some of that will creep in along the way, but we won’t focus on it.All you really need to know about agile for today is: Communicate more, Cut out waste by questioning the process, and work in smaller increments.
- what is a user story: a high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.Typical formatsAs a, I want to becauseAs a temporary library employee, I want to check in these books, so they can be reshelved.Given, when, then – enables more contexts (givens) & outcomes (thens.)Given that I am new here, when a patron returns a book, then enable me to check it in and tell me where it goes.Remember Personas – think about the motivation of the subject of the story. E.g. "As a library patron, I want to log in because ….. why?" A user doesn't want to log in ever. The story may be "As the system owner, I want users to log in so we can ensure proper authorization / use of our data/ system /// .. " Or what else? WHY do we want people to log in? be clear about it.
- How user stories are different from requirements - The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. Focus on user needs. Avoid details of specific technology, data base layout, and algorithms.How user stories are different from Use Cases – What the user wants to do versus specific ways in which the user may do it. ** User stories should typically address only ONE, happy-path scenario for how the system will be used. ***Details usually found in a use case should not be part of the user story. User stories should be one sentence. (Use cases or other dialog about specific use/intention comes later, during development – as a conversation.)What is acceptance criteria? - define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. Essentially – what grade/level of quality is acceptable for the story? (e.g. is a confirmation necessary? Is data validated before saving? Don't just state the story in reverse. "As a patron, I want to find a book in your library." Acceptance: (perhaps) Tell user whether or not we own the book. Tell user whether the book is available. Tell user shelving location. Tell user about other formats.) (e.g. not “Book is found by patron.”)
- How user stories are different from requirements - The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. Focus on user needs. Avoid details of specific technology, data base layout, and algorithms.How user stories are different from Use Cases – What the user wants to do versus specific ways in which the user may do it. ** User stories should typically address only ONE, happy-path scenario for how the system will be used. ***Details usually found in a use case should not be part of the user story. User stories should be one sentence. (Use cases or other dialog about specific use/intention comes later, during development – as a conversation.)What is acceptance criteria? - define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. Essentially – what grade/level of quality is acceptable for the story? (e.g. is a confirmation necessary? Is data validated before saving? Don't just state the story in reverse. "As a patron, I want to find a book in your library." Acceptance: (perhaps) Tell user whether or not we own the book. Tell user whether the book is available. Tell user shelving location. Tell user about other formats.) (e.g. not “Book is found by patron.”)
- The best way to build in flexibility and quality is to remain SIMPLE as long as possible.You *might* assume that the bridge will need to be bigger/ heartier in time .. but the requirement TODAY is to get one person across. Will you still use the wire when this becomes a highway bridge? Probably not – but don't sink enormous pilings to string up a wire just because it'll probably need to be replaced in the future. Today, just get it across as quickly and cheaply as possible – BUT, make sure the structure is sound & safe to use. (i.e. use appropriate architecture that will be easy to modify IF needed.)
- The best way to build in flexibility and quality is to remain SIMPLE as long as possible.You *might* assume that the bridge will need to be bigger/ heartier in time .. but the requirement TODAY is to get one person across. Will you still use the wire when this becomes a highway bridge? Probably not – but don't sink enormous pilings to string up a wire just because it'll probably need to be replaced in the future. Today, just get it across as quickly and cheaply as possible – BUT, make sure the structure is sound & safe to use. (i.e. use appropriate architecture that will be easy to modify IF needed.)
- How to handle iteration zero & infrastructure stories Consider the *other* personas involved in the system:1. As an architect, I want to reduce the time we currently spent on design reviews - so we can get them done earlier in the process.2. As a product owner, I want to use automated tests to ensure quality.3. As a developer, I want to version control my code because I expect to make frequent, incremental changes.
- A few good practices:INVESTKeep stories small , do the simplest thing possibleKeep stories singular - no 'if/else' or 'what if' conditions (Use cases –vs- user stories.) "I want to borrow a book." .. Assume the book is available. Assume I don't have $600 in fines, …Refactoring: In order to add these requirements later, we'll have to create stories & develop them – LATER. Will that mean rework? Probably. Accept it – that's OK. Costs less to rework later than to develop functionality that won't be used or will delay release. When you do refactor: 1) Do it right for the requirements in front of you. 2) Assess the cost of adding the requirement – do you really want it?
- Early stories – focus on delivering value – get the product right first & focus on the inner workings after getting some user feedback. “Go ugly, early.”