SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Build – Measure – Learn is one of the most important mechanisms of agile software development. However, this mechanism is often crippled in nowadays projects, where traditional approaches of requirements gathering are bloating up product backlogs that cannot be prioritized anymore in a meaningful way. The results are customers not interested in iteration results, release to production that happens only at the end of the project, and feedback from customers when it is already too late and the budget is burned up.
Story mapping is a method that aligns user stories along desirable outcomes, so that customers can give sooner meaningful feedback, and release to production can happen earlier. The method helps slicing and prioritizing user stories, and addresses the product design aspect that is missing when just working with a product backlog. The method is highly visual and facilitates shared product ownership among product owner, team and customer.
This presentation provide an introduction to the concept of story mapping, with examples and experience gathered in own projects.
CHRISTIAN HASSA (CH@TECHTALK.AT)TWITTER: @CHRISHASSABudapest Agile MeetUp, May 9th 2013Story Maps in practiceenable early feedback to build what really matters
2About TechTalk• Agile consulting and delivery• Offices: Vienna, Budapest, ZurichTechTalk Team
3Why agile requirements?Successful problem solving requiresfinding the right solutionto the right problem.Russell Ackoff, 1974We fail more often,because we solve the wrong problemthan because we get thewrong solution to the right problem.
5• Describe user needs or features• Unit of planning/prioritization• Future options for evolving the system• Reminder for a conversation• Deferring detail to the last responsiblemomentWhat makes user stories agile?„User stories are really the artifactat the heart of the continuing dialog betweenwhat is possible and what is desirable.“~ Kent Beck (http://c2.com/cgi/wiki?UserStory)
6Impact MappingStory MappingSpecification-By-ExampleDiscovering the problem to solveWhy?How?CodeAcceptanceCriteriaEpicsDeliverables, OutputsImpacts, OutcomesEasier to define upfront Harder to define upfrontUser ActivitiesUser StoriesExamplesGoals
7Specification-By-ExampleDefining experimentsStory MappingUser ActivitiesImpact MappingWhy?How?CodeAcceptanceCriteriaEpicsDeliverables, OutputsImpacts, OutcomesEasier to define upfront Harder to define upfrontUser StoriesExamplesGoals
9Impact MappingFrom: Gojko Adzic: www.impactmapping.orgBased on:Ingrid Domingues,Mijo BalicEffect Managing IT“Impact Mapping helps us plan better!It is collaborative, visual and fast.”
10Impact Map structureGoalActorsImpactsDeliverablesWhat is our goal?Sell 10.000 books within the first 6 monthsafter launching the business.Who can help/prevent us reaching our goal?Shopper of mainstream books,Shopper of rarely available books,Shipping Department, HackersImpact triggering behavior change to help/obstruct goalShopper of mainstream books:• Receive books quicker• find popular books more easilyDeliverables or features supporting/preventingthese impacts (behavior changes):Shopper of mainstream books:• Receive books quicker• order books online• semi-automated distribution center
11Defining Impacts as User StoriesAs a Shopper of mainstream booksI want to order books onlineSo that I can receive books quicker.Sell 10.000 books within thefirst 6 monthsafter launching the business.Actor Impact DeliverableActorImpactDeliverable
12Defining Goals• Scale: What to measure• (Alternative scales to consider)• Meter: How to measure• (Different options how to meter)• Levels• Benchmark: Current Situation• Constraint: Break-Even forInvestment, Minimum AcceptableResult• Target: Desired Result• (Further possible levels: Trend, Fail,Record, Survival)# Monthly ordersof booksSell 10.000 books in thefirst 6 monthsShop systemdatabase01.00010.000Tom Gilb: Competitive Engineering, PLANGUAGE
17Impact MappingSpecification-By-ExampleOptimizing and refining scopeStory MappingWhy?How?CodeAcceptanceCriteriaEpicsDeliverables, OutputsImpacts, OutcomesEasier to define upfront Harder to define upfrontUser ActivitiesUser StoriesExamplesGoals
18Incremental development1 2 3 4 5Requires specifying the solution in detail upfront.Hard to estimate, errors are hard to correct, noadaption possible.Hard to provide feedback on incrementalshipment.From: Jeff Patton, Story Map Workshop
19Iterative development1 2 3Allows to refine the solution.Allows for feedback to better understand theproblem.4 5From: Jeff Patton, Story Map Workshop
20Story Maps• Concept byJeff Patton• Prioritize forimpact/outcome• Optimize designfor user goal• Inject features tosupport userscenario
22WalkingskeletonEnablingbuild – measure - learnFind bookI wantCollectbooksCommitorderWait forbookReceivebooktimebrowsebestsellersenteraddressreceivedeliveryslippay withcreditcardsearchbook bytitlecreatewish listinquiryorderstatusput intobasketreceivedeliverynotificat.necessitymanualworkaroundomittedstepsDoes the deliverableachieve the impact?Impact: Shopper ofmainstream booksreceive books quickerOrder books onlineDoes the impacthelp the business goal?
23Iterative delivery of featuresBase RequirementsMinimum for demo. „walking skeleton“. Not for production.Example: Form with mandatory fields without validation.Capability and FlexibilityVariations of usage. Additional functions, sub-functions.Example: lookup-control, optional fieldsSecuritySecurity for users and stakeholdersExamples: Input validation, additional business rulesUsability, PerformanceMore efficient, attractive, easier to useExample: auto-complete, UI-design, hotkeysFrom: Jeff Patton, Story Map Workshop
24Iterative planning for the release• Opening Game: simplest possible path,„Walking Skeleton“• Mid Game: flexibility, capability and security• End-Game: fine-tuning, performance,buffer for unexpectedtimeuncertainty decreases over timeuncertaintyOpeningGameBuild upnecessitiesMid-GameBuild out flexibilityand business rulesenforcementEnd-GameRefine the UI andinteractions, takeadvantage ofiterative learningFrom: Jeff Patton, Story Map Workshop
25Realized business valueEnd GameFine-tuning in theend.Mid GameBuild features.“Meat” for the“walking skeleton”.Opening GameFocus onunderstanding theproblem. Are webuilding the rightproduct?timerealizedbusinessvalueFrom: Jeff Patton, Story Map Workshop
26Learning curveEnd GameFine-tuning in theend.Mid GameBuild features.“Meat” for the“walking skeleton”.Opening GameFocus onunderstanding theproblem. Are webuilding the rightproduct?timeacquiredproductknowledgeFrom: Jeff Patton, Story Map Workshop
27Story Map Example: eVoting SystemProvision and supportNominate candidatesVote and determine results
38Linking within ALMRefinement forSprint planningLink with Sprint Backlog(Tasks, Taskboard, Burndown)Drill into Details(Specification-By-Example)
39SummaryImpact Maps• Define business goals• Brainstorm impacts on actors to support(not obstruct) business goals• Evaluate deliverables achieving impactStory Maps• Prioritize a deliverable to achieve impact• Optimize a deliverable for user goal• Inject features to support given user scenario