WIXLIB

We need to stop asking usersSince users don’t know how to solve theirproblems, we need to stop asking We need to involve them instead Empirical designParticipatory design Designers of the new systemmake decisions by studyingprospective users in typicalsituations The users of the system becomepart of the team designing thebehavior of the systemAll slides copyright 2000-2005, Mountain Goat Software39Slides copyright 2000-2004, Michael W. CohnStory-writing workshopsIncludes developers, users, customer,others Goal is to write as many stories aspossible No 40prioritization at this pointUses low-fidelity prototyping andbrainstorming techniquesAll slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn20

Start with epics and iterateAs a frequent flyer,I want to seecheck my account.FrequentFlyerAs a frequent flyer,I want to book atrip.As a frequent flyer,I want to book atrip using miles.As a frequent flyer,I want to re-book atrip I make often.As a frequent flyer,I want to requestan upgrade.As a frequent flyer,I want to see if myupgrade cleared. Epic #3 All slides copyright 2000-2005, Mountain Goat Software41Slides copyright 2000-2004, Michael W. CohnA low-fidelity prototypeNewsHome PageNewsHot DealsSearch Fields42Hot Deal DetailsLocation infoWeatherWeatherHotel ResultsList of hotelsBlurb abouteachHotel DetailsInfo about hotelMapLocal attractionsAll slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn21

Low-fidelity prototyping Use paper, note cards, white board, big PostitsPrototype is of components or areas withinthe application, not of actual screens HotelResults could be on Home Page or be aseparate page Doesn’t require knowledge of how screenswill lookThrow it away a day or two laterWorks better to go depth-firstAll slides copyright 2000-2005, Mountain Goat Software43Slides copyright 2000-2004, Michael W. CohnCreating the low-fidelity prototype Start with an empty box: “Here’s the main screen in the system”Ask open-ended, context-free questions as yougo: Whatwill the users most likely want to do next? What mistakes could the user make here? What could confuse the user at this point? What additional information could the user need? 44Consider these questions for each user roleAll slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn22

A mini story-writing workshopWrite some user stories for fBay based onthe roles you identified.Tip: try this template:“As a role , I want to story so that benefit .”All slides copyright 2000-2005, Mountain Goat Software45Slides copyright 2000-2004, Michael W. CohnToday’s agenda Whatuser stories are Users and user roles Gathering stories INVEST in good stories Why user stories?46All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn23

What makes a good story? Independent NegotiableINVEST Valuable Estimatable Small TestableThanks to Bill Wake for theacronym. See www.xp123.com.All slides copyright 2000-2005, Mountain Goat Software47Slides copyright 2000-2004, Michael W. CohnIndependent Avoid introducing dependencies Leadsto difficulty prioritizing and planningA company can payfor a job posting witha Visa card.A company can pay?for a job posting withan AmEx card.A company can payfor a job posting? witha MasterCard. The first of thesestories will take 3 daysto develop It doesn’t matterwhich is first The others will take 1day?48All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn24

Making stories independentCombine the storiesSplit across adifferent dimensionWrite two estimatesand move on A customer can pay with a credit card. A customer can pay with one type ofcredit card. A customer can pay with two othertypes of credit cards. 3 days if first; 1 otherwiseAll slides copyright 2000-2005, Mountain Goat Software49Slides copyright 2000-2004, Michael W. CohnNegotiable Stories are not Written contracts Requirements the software must fulfillDo not need to include all detailsToo many details give the impressions of false precision or completeness that there’s no need to talk further Need some flexibility so that we can adjust howmuch of the story gets implemented Ifthe card is contract then it needs to be estimatedlike a contract50All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn25

Is this story negotiable?Print dialog allows the user to edit theprinter list. The user can add or removeprinters from the printer list. The user canadd printers either by auto-search ormanually specifying the printer DNS nameor IP address. An advanced search optionalso allows the user to restrict his searchwithin specified IP addresses and subnetrange.All slides copyright 2000-2005, Mountain Goat Software51Slides copyright 2000-2004, Michael W. CohnValuable 52Stories must be valuable to either:Users As a user, I can search for a job by titleand salary range.Purchasers Throughout the project, the team willproduce documentation suitable foran ISO 9001 audit. The development team will producethe software in accordance withCMM level 3. All configuration information is readfrom a central location.All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn26

Stories valued by developers Should be rewritten to show the benefitAll connections to thedatabase are througha connection pool.Up to 50 users shouldbe able to use theapplication with a fiveuser database license.All error handling andlogging is donethrough a set ofcommon classes.All errors arepresented to the userand logged in aconsistent manner.All slides copyright 2000-2005, Mountain Goat Software53Slides copyright 2000-2004, Michael W. CohnEstimatableBecause stories are used in planning A story may not be estimatable if: Developers lackdomain knowledge As a new user, I am given adiabetic screening.Developers lacktechnical knowledge As a site visitor, I can elect tosee all text in a larger font.The story is too big54 As a user, I can find a job.All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn27

Small Large stories (epics) are hardto estimate hard to plan Compound story An They don’t fit well into single iterationsepic that comprises multiple shorter storiesComplex story Astory that is inherently large and cannot easily bedisaggregated into constituent storiesAll slides copyright 2000-2005, Mountain Goat Software55Slides copyright 2000-2004, Michael W. CohnCompound stories Often hide a great number of assumptionsAs a user, I canpost my resume.56 A resume includes separatesections for education, priorjobs, salary history,publications, etc. Users can mark resumes asinactive Users can have multipleresumes Users can edit resumes Users can delete resumesAll slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn28

Splitting a compound storySplit along operationalboundaries (CRUD) As a user, I can create resumes, which includeeducation, prior jobs, salary history, publications,presentations, community service, and anobjective. As a user, I can edit a resume. As a user, I can delete a resume. As a user, I can have multiple resumes. As a user, I can activate and inactivate resumes.57All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. CohnSplitting a compound story, cont.Split along data boundaries As a user, I can add and edit educationalinformation on a resume. As a user, I can add and edit prior jobs on aresume. As a user, I can add and edit salary history on aresume. As a user, I can delete a resume. As a user, I can have multiple resumes. As a user, I can activate and inactivate resumes.58All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn29

Other ways to split large storiesRemove cross-cutting concerns Don’t meet performance targets Avoid splitting stories into tasks Avoid the temptation of related changes All slides copyright 2000-2005, Mountain Goat Software59Slides copyright 2000-2004, Michael W. CohnTestable 60Tests demonstrate that a story meets thecustomer’s expectationsStrive for 90 % automationA user must findthe software easyto use.As a novice user, I amable to completecommon workflowswithout training.A user mustnever have towait long for ascreen to appear.New screens appearwithin 2 seconds in95% of all cases.All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn30

Fixing stories1) Assess the stories you’ve written forfBay against the INVEST attributes.2) Rewrite those that are do not meetthese criteria.3) If you can’t figure out how to rewrite astory, save it for class bleSmallTestableAll slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. CohnAs an OEM procurement agent I want the ability to search for suppliers based on criteria placed in aninput interface. The results include the following functionality: I am able to select one or more suppliers from the list of suppliers inthe database against which to perform the query. I input certain criteria into an interface, query the database, andreceive results as to which suppliers meet the criteria. The results are shown in order from highest match to lowest matchwith a symbol to show complete match of required criteria and a barto show overall match. The list should be paginated and have acertain discrete number of returns per page, with next/previous typenavigation. The query should be performed on the Business Factors: Type ofBusiness, Location, and Supplier Size. The query should be performed on technical factors: material,machine type, size, swing, axis.62All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn31

Today’s agenda Whatuser stories are Users and user roles Gathering stories INVEST in good stories Why user stories?All slides copyright 2000-2005, Mountain Goat Software66Slides copyright 2000-2004, Michael W. CohnSo, why user stories? Shift emphasis from writing to talkingIf requirementsare written downthenThe user will getwhat she wantsAt best, she’ll getwhat was written 67“You built what I asked for, but it’s notwhat I need.”All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn32

Actual examplesThe user can enter aname. It can be 127characters. Must the user enter aname? Can it be other than 127chars?The system shouldprominently display awarning messagewhenever the userenters invalid data. What does should mean? What does prominentlydisplay mean? Is invalid data definedelsewhere?All slides copyright 2000-2005, Mountain Goat Software68Slides copyright 2000-2004, Michael W. CohnAdditional reasons Stories are comprehensible Developersand customers understand them People are better able to remember events ifthey are organized into stories†Stories are the right size for planning Support and encourage iterativedevelopment Caneasily start with epics and disaggregatecloser to development time†Bow er, Black, and Turner. 1979.Scripts in Memory for Text.69All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn33

Yet more reasons Stories support opportunistic development Wedesign solutions by moving opportunisticallybetween top-down and bottom-up approaches† Stories support participatory design Participatory The users of the system become part of the team designingthe behavior of the system Empirical designdesignDesigners of the new system make decisions by studyingprospective users in typical situations†Guindon. 1990. Designingthe Design Process.70All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. CohnMost importantly Don’t forget thepurpose The story text we write on cards is lessimportant than the conversations wehave. “Stories represent requirements, theydo not document them.”††Rachel Davies, “The Pow er of Stories,” XP 2001.71All slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn34

Mike Cohn contact information 72mike@mountaingoatsoftware.com(303) 810–2190 (mobile)(720) 890–6110 (office)www.mountaingoatsoftware.comAll slides copyright 2000-2005, Mountain Goat SoftwareSlides copyright 2000-2004, Michael W. Cohn35

Writing Effective User Stories for Agile Requirements Mike Cohn September 26, 2005 . Programming for 20 years Author of User Stories Applied Agile Estimating and Planning Java, C , database programming books Founding member and director of the Agile Alliance and the . Mountain Goat Software 12 User roles Broaden the scope from looking at .