Transcription
User Stories – The Art of Writing Agile RequirementsSpeakers: Susana Esparza & Raj IndugulaCompany: LitheSpeedWebsite: lithespeed.comWelcome to the PMI Houston Conference & Expo and Annual Job Fair 2014 Please set your cell phone to silent mode There will be time at the end of this presentation for you to take a fewmoments to complete the session survey. We value your feedback whichallows us to improve this annual event.1
Agenda for Today’s Workshop Introduction Overview of Agile/Scrum From Vision to Acceptance Criteria¡ ¡ ¡ ¡ Modeling Users & CustomersEpics, Features & User StoriesElaborating from Vision to StoryAcceptance Criteria & Testable Examples Q&A2
An Introductory Exercise1. Find a partner.2. Start telling them about yourself.3. When they hear something you both havein common, they will say “Me Too!” andfind a new partner.3
Problem Context: CommunicationDevelopmentBuildsBusinessWantsQA Tests4
Striking a BalanceBusinessDevelopment5
OverviewAgile & Scrum
The Agile Landscape“Agile” describes a number ofrelated methods.Scrum is the most popular.ScrumScrum/ ScrumXPJeff Sutherland & Ken Schwaber Extreme Programming (XP)Kent Beck, Ward Cunningham, Ron Jeffries KanbanDavid Anderson Scaled Agile Framework (SAFe)Source:2010StateofAgileDean LeffingwellDevelopmentSurvey,VersionOne7
Dealing with ,whotobuilditfor,andhowtobuilditInitial PlanUseagilewhenyouhaveuncertainty aintyWhotobuilditfor:UserUncertainty8Empirical methodsmonitor progress &direct adaptationBetter Plan
Ceremonies and Artifacts of ScrumSprint CycleInitial PlanningInitialDiscovery *Continuous Validation“Ready”FeaturesFor nextSprint or twoLed by Product Owner with help from TeamLed by TeamReleasePlanningDaily ScrumSprintReviewWorkSprint RetroSprintPlanningContinuous DeliveryProductBacklogSprintBacklogBurndown* Discovery is not explicitly part of the Scrum Framework9“Done”FeaturesFor this Sprint
sSprint PlanningProduct OwnerProduct BacklogSprint BacklogTeamRolesShippable FunctionalityDaily ScrumScrumMasterDeliverablesValues, Practices, RulesProcessRetrospectiveBurndownsBlockers10
Tools Product BacklogPrioritized list of all items (PBI) requiredto launch a successful productSprint BacklogTasks to get committedPBIs to done within SprintSizeUser StoryHigh2User StoryHigh3User StoryHigh5User StoryMedium2User StoryMedium13PBIMedium8SB ItemPriorityUser StoryMedium8User StoryHighUser StoryMedium13Task 1PBIMedium20Task 2User StoryLow100 Task 3User StoryLow40User Story500MediumTask 2400300100Burndown/burn-up ChartVisual aid for tracking teamprogress and forecasting expectedcompletion datesPriorityTask 1Task BoardStories and tasks for the Sprinttracked from start to completion200 PB Item011390420 410 400Task 3300User Story140Task 11006030Task 20Low
The Big Picture12
VisionAligning Goals & Constraints
Crafting a Vision StatementFor Target CustomersWho Statement of NeedThe Product NameIs a CategoryThat Compelling Reason to Buy & UseUnlike Competition / AlternativeOur Product DifferentiatorAs described by Geoffrey Moore in Crossing the Chasm(Thanks to Gabrielle Benefield for the reference)14
SimulationRestaurant Finder
Exercise – Prepare a PitchCreate a Vision Poster for yoursimulation project with:1.A product name;2.A product logo;3.A product slogan or jingle; and4.Three (3) compelling reasons to buyyour product.16
PersonasCustomer & User Modeling
Users vs. CustomersUsers interact directly with the systemThey are important to understand, because: Knowledge of current usage patterns helps to design better, moreusable systems. Unsatisfied users will work around the system, nullifying its advantagesand eventually eliminating it.Customers (sponsors) make buying / adoption decisionsThey are also important, because: They have their own wish lists that may have little to do with theirusers’ needs. They make the purchasing decisions, so if they aren’t happy, you won’tget in the door.18
Looking Across Usage Scenarios Personas represent a type of user acrossusage contexts.– One member of our current or desired audiencein a tangible, less ambiguous way.– Provide a name, a face, and a description givingus a mental model of our users allowing us toemphasize with them and predict how they will useour software. Level of detail– Add just enough detail to aid empathy, more detailscan be distracting.– Lightweight personas will suffice for many.19
User Models Summary Use what works user roles, personas, etc., withoutgetting hung up in vocabulary. Prioritize your user(s) and prioritize stories for them. Post big charts (e.g. personas) in team room to aidempathy. Focus testing and evaluation on the right users,identifying test subjects similar to your models. Base models on reality (ethnography / field study): Usability TestingObservationInterviews 20Data AnalysisFeedback FormsSurveys, etc.
Exercise: Create PersonasWho are your most criticalpersonas, or early adopters?1. List potential stakeholders that wouldrepresent the Customers & Users of yourproduct.2. Prioritize these stakeholders and picktwo to elaborate.3. Create at least two personas by writingbrief stories that outline the motivationsand goals of these customers or users.21
User Stories & the BacklogWorking with Agile “Requirements”
User StoriesThe basic user story template is simplistic, it helps usremember a need while providing context.User Role, Persona(Who?)As a customer who drivesI want to find a convenientlylocated branchEnd ResultSo that I can minimize(Why?)driving timeWhatisnotspecified?23Desired Function(What?)
User Stories at a GlanceKey Characteristics High-level descriptions ofdesired functionality and goals“Contracts for conversation”,not all-inclusive requirementsProduct Backlog UserStoryAs a user I want to createan account so that I canshop online.Estimate 13 PointsPriority 1 (High)Vertical slices of the s a user I want toenter my billinginformation.Pulled into the Sprint Backlogfrom Product BacklogContain Acceptance Criteria todefine “Done”UserStory#2Estimate 4 pointsPriority 1 (High)As a user I want toenter my personalinformation.Estimate 4 pointsPriority 1 (High)Work in Agile projects is organized by Units of Value,rather than by Architectural Layer.24Sprint BacklogUser Stories
What Makes a Good Story?IndependentRon Jeffries’ 3 timableSmallTestableBill Wake’s INVEST25
User Stories: Invest - Independent If all stories are independent, any one canbe picked and delivered in isolation For large systems this is nearly impossible! But, minimizing, identifying and prioritizing,dependencies can result in a better backlog Which user story must come first?As prospectI want to registerSo that I canexecute electronictransactionsOrderChecksTransferPay BillsRegisterLoginAs a userI want to pay billsonlineSo that I don’t haveto write checks26PO: I want“Pay Bills”now!
User Stories: Invest - Negotiable Leaving room for give and take and decidethe details when you have more context– High priorities stories should be moreprecisely defined– Low priority stories should have more playAs a driverI want to get directions toconveniently located storesSo that I get there quicklyEssence todayDetailslaterAcceptance Criteria:Show locations on mapShow locations on GoogleMapsDefer details until you are closeto building, in this case updatethe acceptance criteria27
User Stories: Invest - ValuableThe user story must have value to the user and to the businessAs a userI want to have myprevious orders storedin the databaseSo they will be therepermanentlyAs a repeat customerI want to access old ordersSo that I can quicklypurchase the same productsagainAs a customerI want 75% off allpurchasesSo I can save money28There is clearlyvalue to the user,but is there valueto the business?
User Stories: Invest – Estimable/Small If you can’t estimate it, it is either too large, toovague, too risky, or some combination thereof Solutions include adding acceptance criteria,splitting the story, or better defining itAs a customerI want a self service centerSo that I can address basicneeds 24 by 7 by 365 frommy computerToo big?Acceptance Criteria:1.2.3.4.5.Stop payment on checkFind a branchFind an ATMOrder new checkbookGet statement 2 years old29Easier to estimate,perhaps smallenough to completein a few daysAs a customerI want to find an ATMSo that I can makedeposits or with-drawlsoutside of banking hoursAs a customerI want to find a nearbybranchSo that I can conductbusiness in personAs a customerI want to stop paymenton check so that I anprevent a paymentmade in errorAs a customerI want to see mycanceled checks onlineSo that I can confirmtransactions
User Stories: Invest - Testable You need clarity on the story specific done criteriaSolutions include adding acceptance criteriaor better defining the story?Have to manually test, but it isclear.As a registered userI want a better lookinghomepageAcceptance Criteria:So that I don’t have to look at 1. All text is dark color on lightbackground (no more red onsomething so uglyblack)2.Only two different fonts used(instead of seven)30
Epics, Features, StoriesStoriesPriorityFeaturesEpicsProduct backlog31
EpicsEpics are high-level features or activitiesthat span Sprints, or even Releases. Add a Customer Center for self service. Improve database response time by 50%.Logistics The PO works with stakeholders and the Teamto create epics that address desired Goals. Epics are often defined prior to Release Planning. Often months of effort.32
FeaturesFeatures are tangible expressions offunctionality, but still too large to build. As a Bank Customer, find a branch so that I can depositchecks.As a Shopper, set up a mobile wallet so I can pay forpurchases via Near Field Communications.Logistics Created by the PO with input from the teamOften defined prior to Release PlanningDecomposed over time to smaller StoriesTypically weeks of effort33
User StoriesUser Stories are ready for the Team tobuild. As a Bank Customer, find a branch near an address so that Ican minimize travel.As a Shopper, add an account to my mobile wallet so that Ican fund it.Logistics Refined in backlog grooming sessions by POand representatives from Team Stories should be well-defined prior to SprintPlanning Generally about 1-3 days of effort34
Non- Functional Requirements (NFRs) System-wide nonfunctional requirements maybecome part of the Definition of Done. Articulated as tests Serve as design constraintsSearch response time will not exceed 10 seconds.All stories will meet Section 508 accessibilityguidelines. Story-specific NFRs are expressed asAcceptance Criteria.35
What User Stories are NOTUser StoriesRequirements(User Stories è Requirements)3636
Requirements, More than Just a StoryContext (Project Vision, Business Case, etc.) Requirement User Story Conversation(s)AcceptanceCriteria SupportingInformationCommon Understanding of a Need3737
Which Story is Better?ABAs a prospectI want to enter my billinginformationAs a prospectI want to registerSo I can make purchases onlineAs a driverI want to find the store with theshortest drive timeSo I can get there quicklyAs a driverI want to find directions to a store onGoogle MapsSo I can get there quicklyAs a repeat customerI want to access old ordersSo that I can rapidly purchase thesame products againAs a userI want to have my previous ordersstored in the databaseSo they will be there permanentlyAs a color blind userI want dark text & light backgroundSo that I can easily read the textAs a userI want a nice looking siteSo my aesthetics are satisfied38
Exercise – Write User StoriesUsing the Epics we provided for ourawesome restaurant finder app: Create at least five Sprint-sizedUser Stories based on these Epics. Use the “As a, I can, so that”format for the User Stories.39
Release Planning/RoadmappingStory Maps
Mapping Releases with Story MapsUser GoalsAccessrecord Minimize the timeneeded to accesspatient records Minimize the customerinputs necessary toaccess patient recordsNight eWorkflow SequenceProvideNurse IDPriorityPersonaEpicsReleaseBoundaryRobin leaves for work at 6pm, aftersleeping during the day. She works a7pm-7am shift in Labor & Delivery,caring for prospective mothers andtheir babies. Complex computerapps make Robin grumpy.ProvidePatient tify onFilterrecords41Features &User StoriesSearchreferenceAddcomment
Another ExampleThanks to Winnipeg Agilist for this image42
Prioritization ParametersValue is influenced by many things: Time sensitivity – Build features that decay invalue over time earlier. Uncertainty & Risk – Use “spikes” to testmarket or technical viability for critical, riskyfeatures. Size – All else being equal, do the shortest first. External Dependency – Third party or supportgroup dependencies can be immutableconstraints.43
Exercise – Story MappingPlan your first few Releases with aStory Map. Place Epics or High Level Activities at top, inorder of their natural workflow as appropriate. Place User Stories underneath the Epics thatthey support, from top to bottom by value. Group the stories for your first Release (MVP)and subsequent Releases, describing thetargeted benefits of each at a Roadmap level.44
Product Backlog ManagementRefining, Accepting & Testing
Product Backlog EssentialsAdding User Stories Anyone can suggest backlog items Product Owner prioritizes themEstimating & Elaborating High-priority items are estimated anddescribed most precisely, since theywill be worked on first Low-priority items are generallyestimated and described coarselyPrioritizing Ordering is driven mainly by businessvalue and risk reduction.46High priority itemsare better defined#Backlog ItemEstimate1Create login screen1 20Allow user to browserecently viewed items8 60Add personalizationLow priority itemsare often “epics”30 (or so)
Progressive Elaboration3-4 Sprints ahead or more 1-2 Sprints aheadCurrent tureEpicsandFeaturesMarketing/Sales,Product Management,Product roduct Owners,Architects, Dev Leads,QA Leads, roductDemosRetrospecOvesLeads, UX/Analysts,Dev Team Members
Maturation of a User StoryAcceptance CriteriaUser StoriesSprint Pre-Planning (Backlog Grooming)Created during upfront and ongoing DiscoveryAs a userI want to create an accountSo that I can shop onlinePriority – 1 (High) Phone # in US format, contains no alphacharacters, minimum 10 digits First name, Last name and email addressrequired Email specified in standard formatEstimate - 5 PointsSprint TasksTestable Examples (ATDD)Sprint PlanningSprint Pre-Planning (Backlog Grooming)NamePhoneEmailJohn LSE215-555-1212jsmith@ls.comFALSEJohn Smithjsmith@ls.comFALSESmithjsmith@ls.comFALSE Valid48Design UI Mock UpWrite online help textDevelop CSS/HTMLDevelop validation criteriaCreate database tablesCode test fixturesCode & Test
Sample Story Maturation Look-A-HeadThe tactical act of getting a story ready is oftenperformed as a two sprint look-a-head by an amigosteamSprint nSelect User Story 999 for Sprint n 2Re-estimate it, sharpen story &acceptance criteriaThe PO and 3 Amigos looka-head and select story 999for inclusion for Sprint n 2.They do cleanup on the story.Sprint n 1Create testable example and othersupporting material for 999Get sign off from external partiesThe 3 Amigos furthersupport the story and the POgets appropriate sign offs.49Sprint n 2DevelopUser Story 999Story 999 makes it’s way into asprint and it is built.
Approaches to Splitting Storiesds 1.To Demonstrate Progress: UX with no validation or save2.CRUD: Create, report, update & delete (e.g. split of manage)3.Basic to Advanced: Sort by one field (name), sort by any onefield (name, date, etc.), sort by a combination of fields4.Use Case scenarios: Happy path, alternates, exceptions5.Workflow steps: Find book, see details, purchase6.Importance: Credit card, split across cards, automatic billing6.UI complexity: Manual coordinates, interactive web map7.Spike and Build: Research credit card processing, implement5050
Split some StoriesAs a I want to manage my1widgetsAs a report viewerI want to filter my report by2any combination of columnsAs a possible room renterI want to find and book a3roomAs a customer4I want to pay electronically51
Split some StoriesAs a low budget vacationtravelerI want to find flights using a5range of datesAs a credit card purchaserI want to pay by Amex,6MasterCard, Visa or DiscoverAs a frequent userI want to personalize my7experience52
Getting to Ready3 adandensuresweare:1. ReadytoprioriOze2. ReadytoesOmate/rightsize3. Readytobuild53
When is a Story “Ready”?DefiniFonof“Ready” intPlanning. atproducepolishedresultsareyourgoals.þ q q þ þ þ q stableExamplesAcceptanceCriteriaStateDiagramsþ SmallEnoughq Agreementfromotherteamsq Approvals(Compliance,Security,BrandMgmt,etc.)q DependencyListq Stakeholdersignoff54
When is a Story “Done”?DefiniFonof“Done” ders Denoteswhatstoriesrequiretobeaccepted eleasedstateþ þ þ þ q q q oymentTrainingScriptþ q þ q þ þ þ createdOpsdocumentaOoncreated
“Done Done” at Release LevelWhat are theminimum criteria foreach Release? Testing/quality targets Performance targets Operational (e.g. sales/marketing) deploymentgoals Requireddocumentation &artifacts Regulatory compliancetargets 56Example Release CriteriaSystem response on alllevel 1 functions within 5secondsNo Severity 1-3 bugs inFirefox 2 , Chrome, IE 7 or Safari 3 No Severity 1 or 2 bugsfound during final monthFull compliance withaccessibility guidelines inSection 508
Acceptance Criteria &Testing
Acceptance Criteria ExampleAs a userI can cancel a registrationSo that I don’t haveto payq Premiummember can cancel the sameday without a feeq Non-premium member is charged 50% offirst day for a same-day cancellationq Email confirmation is sent to membersprimary and secondary email addressesq Hotel is notified of any cancellation58
Modern Agile Acceptance ModelConditions of Satisfaction –Broad TermsAcceptance Criteria –Further RefinedExamples –Actual scenarios or dataExecutable Examples –Ready to automate59
Acceptance – Conditions of SatisfactionTesting a Registration Function What constraints should we impose? Business stakeholders and PO agree thatpasswords should not be easy tocrack.Please fill in to register.Email AddressPasswordRegister60
Acceptance – Acceptance CriteriaAcceptance Criteria, the DetailsThe PO works w
1 User Stories – The Art of Writing Agile Requirements Speakers: Susana Esparza & Raj Indugula Company: LitheSpeed Website: lithespeed.com Welcome to the P
