Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Story writing and mapping

354 views

Published on

Presentation based on Jeff Patton's book and teachings on story telling and mapping.

Published in: Software
  • Be the first to comment

Story writing and mapping

  1. 1. Story Writing & Mapping presented by Kevin Burns 1-18-2017
  2. 2. Kevin Burns Coach Org Change Agent kburns@sagesw.com, @kevinbburns 2
  3. 3. My work history and experience kburns@sagesw.com, @kevinbburns 3
  4. 4. kburns@sagesw.com, @kevinbburns 4
  5. 5. Peace Corp Recruitment and Public Affairs Story of how we used technology to improve Peace Corp recruitment. Switch from USPS to email Switch from manual data entry to wild-card search in gopher email system and screen scraping results, an early for of ETL. Conduct direct email campaigns when spam still meant ‘meat in a can’ kburns@sagesw.com, @kevinbburns 5
  6. 6. kburns@sagesw.com, @kevinbburns 6
  7. 7. How is value determined? • Is value determined by delivery on time, on budget, and on scope? • Are your features delighting your customers? • Is all scope created equal? • How do you know the value of the scope? kburns@sagesw.com, @kevinbburns 7
  8. 8. In a survey of 4 products, 65% of the features were rarely or never used. How much money could have been saved if we never built them? In the Waterfall project world, we have to ask for everything we can think of because capital will end at the end of the project. Instead we should be asking what has the most value in terms of the business outcome and/or impact and how are we going to measure it. kburns@sagesw.com, @kevinbburns 8
  9. 9. Traditional Process Schedule / CadenceTeam / CostRequirements Schedule / Waterfall Features Agile Approach Team / Cost Stabilize Variable kburns@sagesw.com, @kevinbburns 9
  10. 10. Jeff Patton kburns@sagesw.com, @kevinbburns 10
  11. 11. What do you see? Seven Habits of Highly Effective People - Stephen Covey kburns@sagesw.com, @kevinbburns 11
  12. 12. Telephone Game – Cake Requirements kburns@sagesw.com, @kevinbburns 12
  13. 13. Do we all have the same understanding? How do we know? User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 13
  14. 14. Stop trying to write perfect documents Good documents are like vacation photos Document to help remember Take a picture of your work to help remember User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 14
  15. 15. Your job isn’t to write better docs, it’s to change the world. Can you turn your work into a Vocation? kburns@sagesw.com, @kevinbburns 15
  16. 16. Stories create Understanding • Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding. • Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build. • Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 16
  17. 17. Focus on User Interactions Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton Good story conversations are about who and why, not just what. kburns@sagesw.com, @kevinbburns 17
  18. 18. Where to start? • There’s always more to build than you have people, time, or money for. • The goal shouldn’t be to implement everything we can think of, rather what is the minimal amount we should implement to achieve desired impact. • Start with the most important user/customer. • Map for a product release across multiple teams to visualize dependencies. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 18
  19. 19. Story Mapping Mechanics • Mapping your story helps you find holes in your thinking. • Map only what you need to support your conversation. • Reorganizing cards together allows you to communicate without saying a word. • Focus on the breadth of the story before diving into the depth. • Use short verb phrases to capture what the user wants to do. • Scope doesn’t creep; understanding grows. • Focus on what you hope will happen outside the system to make decisions about what’s inside the system. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 19
  20. 20. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 20
  21. 21. Release slicing (roadmap) – MVP for release? Don’t Prioritize Features Prioritize Outcomes User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 21
  22. 22. Minimum Viable Product (MVP) defined • The minimum viable product is the smallest product release that successfully achieves its desired outcomes. • Minimum is a subjective term. So be specific about who it’s subjective to— because it’s not you. Be specific about who your customers and users are, and what they need to accomplish. What’s minimum to them? • The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes. • A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption. Eric Reis – Lean Startup • Minimum viable product experiment • Minimum valuable solution/product User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 22
  23. 23. What’s the Opportunity? • What is the big idea? • Who are the customers? • Who are the users? • Why would they want it? • What problems would it solve for customers and users that they couldn’t solve today? • What benefit would they get from buying and using it? • Why are we building it? • If we build this product and it’s successful, how does that help us? User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 23
  24. 24. Test your assumptions and hypothesis • Validate that the problems you’re solving really exist. • Prototype and test with users to learn whether your solution is valuable and usable. • Users want more than they use. (50-80% more) • Build > Measure > Learn, rinse and repeat • Development Partners (from the business) help validate your assumptions and hypothesis • Iterate until Viable/Valuable is achieved User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 24
  25. 25. Bad Release Strategy Good Release Strategy Treat every release as an experiment and be mindful of what you want to learn. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 25
  26. 26. User Story Mechanics • User tasks are the basic building blocks of a story map. • Use the goal-level concept to help you aggregate small tasks or decompose large tasks. • Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story. • Details, alternatives, variations, and exceptions fill in the body of a map. “What about…?” • Activities aggregate tasks directed at a common goal. • Activities and high-level tasks form the backbone of a story map. • Use slices to identify all the tasks and details relevant to a specific outcome. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 26
  27. 27. User Story Mechanics Summary • Tasks are short verb phrases that describe what people do. • Tasks have different goal levels. • Tasks in a map are arranged in a left-to-right narrative flow. • The depth of a map contains variations and alternative tasks. • Tasks are organized by activities across the top of the map. • Activities form the backbone of the map. • Slice map to identify tasks you’ll need to reach a specific outcome. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 27
  28. 28. 6 Steps to Story Mapping 1. Frame the problem 2. Map the big picture 3. Explore users and interactions 4. Slice out a release strategy 5. Slice out a learning strategy 6. Slice out a development strategy User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 28
  29. 29. More on Why • We can both read the same document, but have a different understanding of it. • Kent Beck’s simple idea was to stop trying to writing the perfect document, and to get together to tell stories. • Stories get their name from how they’re supposed to be used, not from what you’re trying to write them. • If you’re not getting together to have rich discussions about your stories, then you’re not really using stories. • The best solutions come from collaboration between the people with the problems to solve and the people who can solve them. • Story conversations are about working together to arrive at the best solution to a problem we both understand. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 29
  30. 30. Ron Jeffries 3 Cs from Extreme Programming Installed Card: Write what you’d like to see in the software on index cards. Conversation: Have a rich conversation about what to build. Confirmation: Agree on how you’ll confirm definition of done. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 30
  31. 31. Story card attributes • Title (name) • Description (Who, What, Why) • Acceptance Criteria (Definition of Done) • Story number • Estimate, size, or budget • Value • Metrics • Dependencies • Status • Dates User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 31
  32. 32. Working remotely • Use a document camera or web camera during a video conference to let remote people see what’s being created on the wall. • When collaborating remotely, use tools that allow everyone to see, add to, and organize the model concurrently. • Use tools to post pictures, videos, and text to help you retain and remember your conversations. • Use tools to sequence, track, and analyze progress. • Handing off all the details about the story to someone else to build doesn’t work. Don’t do that. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 32
  33. 33. For every story, there are two to follow. Alistair Cockburn • In a traditional process, learning gets referred to as scope creep or bad requirements. • In an Agile process, learning is the purpose. • Plan on learning from everything you build. • Plan on being wrong at least half the time. • Validated learning over working software (or comprehensive documentation) Kent Beck • Try using stories to drive the making of anything, whether it’s software or not. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 33
  34. 34. Decompose • If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal. • If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner. • Don’t break down big things into big plans. Break big things into small things with small plans. • You can deliver “half a baked cake, not a half-baked cake.” User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 34
  35. 35. Right-sizing • A right-sized story from a business perspective is one that helps a business achieve a business outcome. • A right-sized story from a user’s perspective is one that fulfills a need. • A right-sized story from a development team’s perspective is one that takes just a few days to build and test. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 35
  36. 36. Conversations are one of the best tools for breaking down big stories. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton kburns@sagesw.com, @kevinbburns 36
  37. 37. Spike Stories • From the Extreme Programming community • Effort designed to learn • Might not result in shippable code • Should be timeboxed (<20hrs) • Impacts team capacity • Most teams don’t put story points on them until they know whether or not it will become real work intended for release. (they don’t want to inflate velocity for stuff that might not ship) kburns@sagesw.com, @kevinbburns 37
  38. 38. MVP Innovation User UX, BA, QA, SME Business Valuable Design Usable Software Engineering AD, DD, DA Business Customer PO, SM, BL Use scientific method (measurable) to learn and discovery your Minimum Viable (Valuable) Product (MVP) Technically Feasible MVP innovations emerge from Conversations kburns@sagesw.com, @kevinbburns 38
  39. 39. INVEST in stories •Independent – stand-alone •Negotiable – there is more than one way to implement/solve •Valuable – useful and ROI •Estimable – we’re able to size it •Small – deliverable within a few days •Testable – can validate when done http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ kburns@sagesw.com, @kevinbburns 39
  40. 40. Define SMART story tasks •Specific – discrete, known •Measurable – testable, DoD •Achievable – owner has skills to deliver it •Relevant – needed to deliver story effectively •Time-boxed – there is an understanding of duration http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ kburns@sagesw.com, @kevinbburns 40
  41. 41. Story writing options This can work for System as user • Given a certain precondition situation • When a certain interaction occurs • Then the system does this An example: • Given my bank account is in credit, and I made no withdrawals recently, • When I attempt to withdraw an amount less than my card's limit, • Then the withdrawal should complete without errors or warnings http://martinfowler.com/bliki/GivenWhenThen.html kburns@sagesw.com, @kevinbburns 41
  42. 42. Story Mapping Exercise Options • Tasks when you wake-up in the morning • Flight booking system • Real scenario from work kburns@sagesw.com, @kevinbburns 42
  43. 43. ? kburns@sagesw.com @kevinbburns 612-396-7724 kburns@sagesw.com, @kevinbburns 43

×