Your SlideShare is downloading. ×
0
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Presentation

420

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
420
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
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
  • 177
  • p88
  • 137
  • 134
  • 145
  • 151
  • 157
  • Transcript

    • 1. User Stories Applied For Agile Software Development by Mike Cohn Mike Kaiser
    • 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. 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. 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. 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. 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. 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. What is a User Story?
    • 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. 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. 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. 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. User Role Modeling
    • 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. 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. 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. 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. Gathering Stories
    • 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. 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. 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. 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. 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. Estimating User Stories
    • 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. 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. 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. 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. What Stories Are Not
    • 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. 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. Why User Stories?
    • 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. 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. 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. 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. 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. 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. 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. 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>

    ×