User Stories for Agile Requirements. Mike Cohn - background. Copyright Mountain Goat Software, LLC

Transcription

1 User Stories for Agile Requirements 1 Mike Cohn - background 2

2 It s a communication problem Software requirements is a communication problem Those who want software must communicate with those who will build it 3 Balance is critical If either side dominates, the business loses If the business side dominates functionality and dates are mandated with little regard for reality or whether the developers understand the requirements If the developers dominate technical jargon replaces the language of the business and developers lose the opportunity to learn from listening 4

3 Resource allocation We need a way of working together so that resource allocation becomes a shared problem Project fails when the problem of resource allocation falls too far to one side 5 Responsibility for resource allocation 6

4 Imperfect schedules We cannot perfectly predict a software schedule As users see the software, they come up with new ideas Too many intangibles Developers have a notoriously hard time estimating If we can t perfectly predict a schedule, we can t perfectly say what will be delivered 7 So what do we do? 8

5 Today s agenda What stories are User role modeling Story writing INVEST in good stories What user stories are not Why user stories 9 Ron Jeffries Three Cs Source: XP Magazine 8/30/01, Ron Jeffries. 10

6 Samples from a travel website 11 Where are the details? As a user, I can cancel a reservation. Does the user get a full or partial refund? Is the refund to her credit card or is it site credit? How far ahead must the reservation be cancelled? Is that the same for all hotels? For all site visitors? Can frequent travelers cancel later? Is a confirmation provided to the user? How? 12

7 Details added in smaller sub-stories 13 Details as conditions of satisfaction The product owner s conditions of satisfaction can be added to a story These are essentially tests 14

8 An example Implementation-size stories; days to implement An epic; weeks to implement 15 An example 16

9 Today s agenda What stories are User role modeling Story writing INVEST in good stories What user stories are not Why user stories 17 The User Many projects mistakenly assume there s only one user: The user Write all stories from one user s perspective Assume all users have the same goals Leads to missing stories 18

10 Travel Site Who s the user? 19 User roles Broaden the scope from looking at one user Allows users to vary by What they use the software for How they use the software Background Familiarity with the software / computers Used extensively in usage-centered design Source: Software for Use by Constantine and Lockwood (1999). 20

11 Common attributes 21 Advantages of using roles 22

12 Today s agenda What stories are User role modeling Story writing INVEST in good stories What user stories are not Why user stories 23 Questioning the users A problem: The question is closed {Yes No} 24

13 We can do better It s open Full range of answers But it has too much context 25 The best way to ask We want to ask questions that are Open-ended Context-free 26

14 Context matters 27 My context isn t your context 28

15 It s my problem, I know the solution Having a problem does not uniquely qualify you to solve it It hurts when I go like this 29 We need to stop asking users Since users don t know how to solve their problems, we need to stop asking We need to involve them instead 30

16 Story-writing workshops Includes developers, users, customer, others Brainstorm to generate stories Goal is to write as many stories as possible Some will be implementation ready Others will be epics No prioritization at this point 31 Start with epics and iterate 32

17 Today s agenda What stories are User role modeling Story writing INVEST in good stories What user stories are not Why user stories 33 What makes a good story? Thanks to Bill Wake for help with the acronym. See 34

18 INVESTing in good stories Independent Dependenices lead to problems estimating and prioritizing Can ideally select a story to work on without pulling in 18 other stories Negotiable Stories are not contracts Leave or imply some flexibility Valuable To users or customers, not developers Rewrite developer stories to reflect value to users or customers 35 INVESTing in good stories Estimatable Because plans are based on user stories, we need to be able to estimate them Sized Appropriately Testable Stories need to be testable Complex stories are intrinsically large Compound stories are multiple stories in one 36

19 Today s agenda What stories are User role modeling Story writing INVEST in good stories What user stories are not Why user stories 37 Software requirements specs Problems with IEEE 830-style Software Requirements Specifications Tedious to read So readers skim or skip sections Assumes everything is knowable in advance Feedback 38

20 All requirements are not equal Designers fix a top-level concept based on their initial understanding of a problem. May produce a solution for only the first few requirements they encounter. Sources: Making Use by John M. Carroll (2000) and Technology and Change by D.A. Schon (1967). 39 What are we building? Source: Adapted from The Inmates are Running the Asylum by Alan Cooper (1999). 40

21 What if we had stories instead? 41 The product 42

22 Stories are not use cases 43 Stories are not use cases 44

23 Differences: use cases / stories Scope Completeness Longevity Purpose Use cases document an agreement between the customer and the developers User stories are reminders to have a conversations and are written to facilitate planning 45 Today s agenda What stories are User role modeling Story writing INVEST in good stories What user stories are not Why user stories 46

24 So why user stories? Shift focus from writing to talking then You built what I asked for, but it s not what I need. 47 Words are imprecise 48

25 Examples 49 Another example 50

26 Additional reasons Stories are comprehensible Developers and customers understand them People are better able to remember events if they are organized into stories Support and encourage iterative development Can easily start with epics and disaggregate closer to development time Bower, Black, and Turner Scripts in Memory for Text. 51 Yet more reasons Stories are the right size for planning Stories support participatory design Stories support opportunistic development We design solutions by moving opportunistically between top-down and bottom-up approaches Guindon Designing the Design Process. 52

27 Why not user stories? There are some drawbacks to be aware of On a large project there can be lots of stories Solution is to remember to keep some as epics initially Or staple some together into themes Stories on cards don t facilitate traceability But you can do it, or you can use software Stories focus on increasing tacit, not formal, communication May need to supplement with some formal documentation 53 Most importantly 54

28 Upcoming public classes Date What Where August 1-2 Certified ScrumMaster Denver August 3 Agile Estimating & Planning Denver November 7-8 Certified ScrumMaster Santa Clara November 9 Agile Estimating & Planning Santa Clara November Certified Product Owner (with Ken Schwaber) Boulder Register at 55 Mike Cohn contact info mike@mountaingoatsoftware.com (720) (office) (303) (mobile) 56