Presentation

523 views
468 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
523
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 177
  • p88
  • 137
  • 134
  • 145
  • 151
  • 157
  • Presentation

    1. 1. User Stories Applied For Agile Software Development by Mike Cohn Mike Kaiser
    2. 2. Mike Kaiser <ul><li>Over 5 years doing software in the insurance industry (development, testing, business analysis, solution analysis) </li></ul><ul><li>Certified Product Owner </li></ul><ul><li>Currently on second multi-million dollar agile initiative at Nationwide </li></ul>
    3. 3. Approach <ul><li>I have some experience, but this isn’t my book we are talking about </li></ul><ul><li>If I don’t know the answer, I will do my best to say just that. Perhaps these are opportunities where we can learn from you </li></ul><ul><li>Agile is not prescriptive. Your project is unique, you are unique </li></ul>
    4. 4. Agenda <ul><li>Overview / Why Change </li></ul><ul><li>Writing Stories / INVEST </li></ul><ul><li>User Role Modeling </li></ul><ul><li>Gathering Stories </li></ul><ul><li>User Proxies </li></ul><ul><li>Estimating User Stories </li></ul><ul><li>Why User Stories </li></ul><ul><li>Additional Topics </li></ul>Our “stories” interjected throughout… I would rather not cover all of this if we get a lot of value out of what we do cover
    5. 5. Introduction <ul><li>Software requirements is a communication problem </li></ul><ul><li>This is normally between customers (incl. users/analysts/ domain experts), and a technical team. </li></ul>
    6. 6. Need To Work Together <ul><li>When business dominates </li></ul><ul><ul><li>mandates functionality/dates with little concern that developers can meet both or if it is understood what is needed </li></ul></ul><ul><li>When developers dominate </li></ul><ul><ul><li>technical jargon replaces the language of the business and developers lose the opportunity to learn by listening </li></ul></ul>
    7. 7. How Predictable? <ul><li>We cannot perfectly predict software development </li></ul><ul><ul><li>Users see early versions of software, they come up with new ideas and opinions change </li></ul></ul><ul><ul><li>Because of the intangibility of software, most developers have a difficult time estimating how long things will take </li></ul></ul><ul><ul><li>As such, we cannot lay out a perfect PERT chart showing all that must be done on a project </li></ul></ul>
    8. 8. What is a User Story?
    9. 9. Example <ul><li>As a customer service representative, I can search for a customer so that I can view their account details. </li></ul><ul><ul><li>When searching by a valid account number, the account is shown </li></ul></ul><ul><ul><li>When searching by a valid name and SSN, the account is shown </li></ul></ul><ul><ul><li>If no results are found, show appropriate message </li></ul></ul><ul><ul><li>Acceptance tests? </li></ul></ul>
    10. 10. Some Guidelines <ul><li>Generally smaller scope is better </li></ul><ul><ul><li>and must be small enough to be completed by one pair in an iteration </li></ul></ul><ul><li>Generally the fewer the written details, the better </li></ul><ul><li>Anyone can write a story </li></ul><ul><ul><li>why limit who can have a good idea? </li></ul></ul><ul><ul><li>(does not mean it will be developed nor developed with those details) </li></ul></ul>
    11. 11. INVEST <ul><li>Independent </li></ul><ul><li>Negotiable </li></ul><ul><li>Valuable (to users/customers) </li></ul><ul><li>Estimatable </li></ul><ul><li>Small </li></ul><ul><li>Testable </li></ul><ul><li>Our Experiences </li></ul><ul><li>From Bill Wake, Extreme Programming Explored and Refactoring Workbook </li></ul>
    12. 12. Story Responsibilities <ul><li>Developer </li></ul><ul><ul><li>To help customers write stories that are promises to converse rather than detailed specs and that are INVEST </li></ul></ul><ul><ul><li>If tempted to ask for a story about the use of a technology, instead describe the need in terms of its value to users/customer </li></ul></ul><ul><li>Customer </li></ul><ul><ul><li>Write promises to converse rather than detailed specs and INVEST </li></ul></ul>
    13. 13. User Role Modeling
    14. 14. Why User Role Modeling? <ul><li>Many projects just do requirements from the perspective of “user” </li></ul><ul><li>This simplification can be a fallacy that leads the team to miss stories </li></ul>
    15. 15. User Role Modeling Steps <ul><li>Brainstorm an initial set of user roles </li></ul><ul><ul><li>Generally don’t need system roles </li></ul></ul><ul><ul><li>Want to focus on the main user bases </li></ul></ul><ul><li>Organize the initial set </li></ul><ul><li>Consolidate roles </li></ul><ul><li>Refine the roles </li></ul><ul><ul><li>Frequency of their use </li></ul></ul><ul><ul><li>Level of expertise with the domain </li></ul></ul><ul><ul><li>General level of proficiency with computers </li></ul></ul><ul><ul><li>Level of proficiency with software under dev. </li></ul></ul><ul><ul><li>General goal for using software (convenience, rich experience) </li></ul></ul><ul><li>How long we spent. What we found. </li></ul>
    16. 16. Additional Techniques <ul><li>Personas </li></ul><ul><li>Extreme Characters </li></ul><ul><ul><li>For a PDA: </li></ul></ul><ul><ul><ul><li>Drug dealer </li></ul></ul></ul><ul><ul><ul><li>Pope </li></ul></ul></ul><ul><ul><ul><li>a 22 year old woman who is juggling multiple boyfriends </li></ul></ul></ul>
    17. 17. User Role Responsibilities <ul><li>Developer </li></ul><ul><ul><li>Participate in identification process </li></ul></ul><ul><ul><li>Understand each user role </li></ul></ul><ul><ul><li>While developing, consider how different roles prefer software to behave </li></ul></ul><ul><li>Customer </li></ul><ul><ul><li>Looking broadly in identification </li></ul></ul><ul><ul><li>Ensure software focuses appropriately on the different roles/personas </li></ul></ul><ul><ul><li>When writing stories ensure they are for at least one role/persona </li></ul></ul>
    18. 18. Gathering Stories
    19. 19. Is It Elicitation and Capture Time? <ul><li>Terms like these imply requirements are “out there”. We just need them explained to us so we can lock them in a cage.  </li></ul><ul><li>Requirements not out in space waiting to be captured. Not a case of users already knowing requirements and just needing to elicit them. </li></ul><ul><li>What’s a better metaphor??? </li></ul>
    20. 20. Trawling <ul><li>Mental image that req. are captured in a fishing net </li></ul><ul><li>Different-sized nets can be used to capture different-sized req. (can do multiple passes) </li></ul><ul><ul><li>“ size” can be biz value, complexity, etc. </li></ul></ul><ul><li>Requirements, like fish, can grow in importance or shrink and die. </li></ul><ul><li>You will not catch it all the first time and you will catch some flotsam </li></ul><ul><li>Skilled practitioners will know where to look for stories </li></ul>
    21. 21. Story-Writing Workshops <ul><li>Includes developers, users, product owner, and others </li></ul><ul><li>Low, low, fidelity prototype (made in the meeting, destroyed soon after) </li></ul><ul><ul><li>Start with a role/persona, then iterate through each of them </li></ul></ul><ul><ul><li>Brainstorm “components” (could be a page, or section of a page … doesn’t matter) </li></ul></ul>
    22. 22. Story-Writing Workshop Pt2 <ul><li>Go through each “component” and brainstorm </li></ul><ul><ul><li>There is no lengthy debate on cards and limited negative feedback. Quantity over quality is the goal here </li></ul></ul><ul><ul><li>Have a visible parking lot </li></ul></ul><ul><ul><li>Want high level discussions. Again, goal is for as many stories as possible in a short time </li></ul></ul>
    23. 23. Nonfunctional Requirements <ul><li>Many can be expressed as “constraint stories”. Automated tests can then be put in place and run each day </li></ul><ul><li>Others cannot, and may need to be expressed in some other appropriate or traditional way </li></ul>
    24. 24. Estimating User Stories
    25. 25. “ When will you be done with these features?” – Your Executive <ul><li>Best approach for estimating stories would be one that: </li></ul><ul><ul><li>Allows us to change our mind when we have new information on a story </li></ul></ul><ul><ul><li>Works for both epics and small stories </li></ul></ul><ul><ul><li>Does not take a long time </li></ul></ul><ul><ul><li>Is tolerant of imprecision in estimates </li></ul></ul><ul><ul><li>Can be used to plan releases </li></ul></ul>
    26. 26. Story Points <ul><li>Ideal days – better than elapsed time or nebulous units </li></ul><ul><li>Estimate as a team – the team needs to own the estimate </li></ul><ul><li>Delphi technique (on index cards) or party poker cards </li></ul><ul><li>Triangulation </li></ul><ul><li>Velocity and Central Limit Theorem </li></ul>
    27. 27. Estimation Responsibilities <ul><li>Developer </li></ul><ul><ul><li>Giving honest estimates </li></ul></ul><ul><ul><li>Estimating as a team </li></ul></ul><ul><ul><li>Consistent. Example, all 2 point estimates are similar </li></ul></ul><ul><li>Customer </li></ul><ul><ul><li>To participate in estimation meetings by answering questions and clarifying </li></ul></ul><ul><ul><li>Not allowed to estimate stories yourself </li></ul></ul>
    28. 28. Measuring Velocity <ul><li>Fully “done, done” story points are counted </li></ul><ul><li>Partially completed stories do not count at all </li></ul><ul><ul><li>Don’t imply precision by saying you completed 4.7 points out of 8 </li></ul></ul><ul><ul><li>That last 10% can take 90% of the time </li></ul></ul><ul><ul><li>The business value is not achieved until it is done, done (or do smaller stories) </li></ul></ul><ul><li>The actual velocity of the last two iterations is the planned velocity of the next </li></ul>
    29. 29. What Stories Are Not
    30. 30. Stories are not Use Cases <ul><li>Stories are smaller (<=10 points) </li></ul><ul><li>UCs are long-living artifacts </li></ul><ul><li>It is hard to keep interface requirements out of a UC. Story names are written from the perspective of business value (the rest is a conversation) </li></ul><ul><li>Contract vs. conversation </li></ul>
    31. 31. Documents Handed-Off Are A Warning Sign <ul><li>Ping pong of a document </li></ul><ul><li>Technical groups rewrite it (calling it something new, like Functional Specification) to hide same information different perspective </li></ul><ul><li>Specs for complex projects are too big to read and hard to write with desired precision </li></ul><ul><li>Blame Game (implied features or hidden out-of-scope statements) </li></ul><ul><li>With conversations, nothing is final. We can always talk again </li></ul><ul><ul><li>Is this a good idea? </li></ul></ul>
    32. 32. Why User Stories?
    33. 33. Stories Emphasize Verbal Communication <ul><li>Humans did not have written words for centuries </li></ul><ul><li>Assumption that if something is written down, there is no ambiguity </li></ul><ul><li>Lunch Menu: “Entrée comes with choice of soup or salad and bread.” </li></ul><ul><ul><li>Soup or (Salad and Bread) </li></ul></ul><ul><ul><li>(Soup or Salad) and Bread </li></ul></ul>
    34. 34. Perfect? <ul><li>Traditional requirements seek to be “perfect” </li></ul><ul><li>Can seem lofty and unattainable </li></ul><ul><li>Even if you could get to perfectly explained written words </li></ul><ul><ul><li>Users refine their opinions as they learn more </li></ul></ul><ul><ul><li>Problems of deferred defects and of verbal agreements undocumented when analyst capacity is low </li></ul></ul>
    35. 35. Stories are Comprehensible <ul><li>Because stories are short, there is a better chance they will be read </li></ul><ul><li>Because stories are written to show customer value, they are comprehensible to business and technical people </li></ul>
    36. 36. Stories Are The Right Size For Planning <ul><li>It is very hard to prioritize sections of a UC </li></ul><ul><li>With stories it is much easier to prioritize scope </li></ul>
    37. 37. Stories Work For Iterative Development <ul><li>Do not need to write all stories before beginning coding </li></ul><ul><li>Can write stories at whatever level of detail is appropriate (epics, last responsible moment) </li></ul><ul><li>Can iterate on top of the stories from previous iterations </li></ul>
    38. 38. Can we find all requirements and then design it in a top-down manner? <ul><ul><li>Customers do not know exactly what they want </li></ul></ul><ul><ul><li>Even if developers know all requirements, many details they need only become clear as the develop </li></ul></ul><ul><ul><li>Even if all details could be known up front, humans are incapable of comprehending that many details </li></ul></ul><ul><ul><li>Even if we could understand the details, product and project changes occur. </li></ul></ul><ul><ul><li>People make mistakes. </li></ul></ul>
    39. 39. Stories Support Opportunistic Development <ul><li>Developers work best by freely moving between requirements, designing at levels of abstraction, and development </li></ul><ul><li>Allows developers see opportunities and then adjust design and approach </li></ul><ul><li>Stories allow: </li></ul><ul><ul><li>Users not knowing everything up front </li></ul></ul><ul><ul><li>Developers not being able to fully comprehend a vast array of details </li></ul></ul><ul><ul><li>Embracing change </li></ul></ul>
    40. 40. Story Smells <ul><li>Interdependent Stories </li></ul><ul><li>Goldplating </li></ul><ul><li>Too Many Details (not INVEST) </li></ul><ul><li>Thinking Too Far Ahead (waterfall mindset) </li></ul>

    ×