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.

IIT Academy: 203 Story Mapping

556 views

Published on

IIT Academy: Agile. Do you know your minimum viable product? Your steel thread? Is your product owner unsure of what to build or what order to build it in? Have trouble articulating technical debt, architectural dependencies and facing large amounts of delivery risk? The new backlog is a 2D map of user stories – learn to master them here. Designed for Product Owners, Entrepreneurs, Delivery Leads, Business Analysts, UX and other designers.

Published in: Leadership & Management
  • Be the first to comment

IIT Academy: 203 Story Mapping

  1. 1. HI Per Lean Practice STORY MAPPING 203 IIT Academy Industrie IT Story Mapping 203
  2. 2. HI Per Lean Practice STORY MAPPING 203 Feel free to re-use any of these slides - you are welcome!
 Please make sure you attribute them to: Steven Ma at Industrie IT. Please include the links at www.stevenhkma.com and industrieit.com Attributions
  3. 3. HI Per Lean Practice STORY MAPPING 203 Contents 1. Recap User Stories • Define • Characteristics of good stories • Usage 2. Planning valuable incremental releases • Identifying value • Identifying valuable releases 3. (Stretch) Building iterative software • Iterative/Incremental construction strategy • Planning for upcoming development
  4. 4. HI Per Lean Practice STORY MAPPING 203 Recap User Stories 1. Recap User Stories • Define • Usage 2. Planning valuable incremental releases • Identifying value • Identifying valuable releases 3. (Stretch) Building iterative software • Iterative/Incremental construction strategy • Planning for upcoming development
  5. 5. HI Per Lean Practice STORY MAPPING 203 User Stories: Define Stories  are  a:   • User’s  need   • Product  descrip3on   • Planning  item   • Token  for  a  conversa3on   • Mechanism  for  deferring  conversa3on *"Kent Beck coined the term user stories in Extreme Programming Explained 1st Edition, 1999
  6. 6. HI Per Lean Practice STORY MAPPING 203 WORKSHOPS User Stories: Define • basic unit of functionality • gain detail over time • adds value to the product • vertical slice through the product • summarised as: • “As a <type of user> I want <some goal>
 so that <some reason>” • has acceptance criteria • can be used to capture non-functional requirements • can be a spike • may include wireframes, solution details etc. ACCEPTANCE CRITERIA FLOWS – SCREEN, DATA, LOGIC, ET AL. ARCHITECTURE – DATA, INFRA, ET AL. WIREFRAMES USER STORY UX ARCH DEV OPS RELEASE are “boundary objects”
  7. 7. HI Per Lean Practice STORY MAPPING 203 9"©"Jeff"Pa)on,"all"rights"reserved,"www.AgileProductDesign.com" User"Stories"are"boundary"objects" A"boundary"object"is"a"concept"in"sociology"to"describe" informaDon"used"in"different"ways"by"different"communiDes." They"are"plasDc,"interpreted"differently"across"communiDes"but" with"enough"immutable"content"to"maintain"integrity "FF Wikipedia" They"are"weakly"structured"in"common"use,"and"become" strongly"structured"in"individualFsite"use."They"may"be"abstract" or"concrete."They"have"different"meanings"in"different"social" worlds"but"their"structure"is"common"enough"to"more"than"one" world"to"make"them"recognizable"means"of"translaDon."The" creaDon"and"management"of"boundary"objects"is"key"in" developing"and"maintaining"coherence"across"intersecDng"social" worlds. "FF"Leigh"&"Griesemer" "
  8. 8. HI Per Lean Practice STORY MAPPING 203 When do we do story mapping?
  9. 9. HI Per Lean Practice STORY MAPPING 203 PRODUCT OWNER ENVIRONMENTAL MARKET FORCES PRODUCT BACKLOG DELIVERY LEAD SPRINT BACKLOG PLANNING POKER STORY BOARDS BURN-DOWN CHART PLANNING PART 1 PLANNING PART 2 DAILY STAND-UP RETROSPECTIVE DEFINITION OF DONE SHOWCASE THE SPRINT GROOMING PRE-DELIVERY STAKEHOLDERS SCRUM TEAM
  10. 10. HI Per Lean Practice STORY MAPPING 203 WHY WHAT DELIVERY • Customer needs understood • Strategic alignment • Initial scope defined • Architecture assessment • Risk and security assessment • Business value assessment • Indicative size estimate • Identify stakeholders • Feature scope defined • Feature backlog prioritised and MVP • Feature t-shirt sized • High-level solution design • High level user interface/ design • Release plan (Feature level) • High-level people assignments and resourcing • Business Case • Solution architecture • Ready-for-work features • Delivery plan
  11. 11. HI Per Lean Practice STORY MAPPING 203 User Stories: Usage Product Backlog • prioritised list of all possible user stories for the product • managed/groomed by the Product Owner • created during insight/inception • higher priority user stories more detailed than lower priority • Scrum team determines sizing/estimates of user stories • user stories can be grouped into features Story mapping • Minimum Viable Product a.k.a. the MVP • Steel Thread can be identified to reduce risk HIGH DETAIL • SPECIFIC • BROKEN DOWN INTO STORIES • READY FOR SPRINT MEDIUM DETAIL • FEATURE-LEVEL • ACTIVELY GROOMED • RELEASE PLANNING LOW DETAIL • IDEAS • FUTURE WORK • SOME PORTFOLIO/ PIPE LINE MANAGEMENT STORY#1STORYN+1STORYN+X…
  12. 12. HI Per Lean Practice STORY MAPPING 203 Recap User Stories 1. Recap User Stories • Define • Usage 2. Planning valuable incremental releases • Identifying value • Identifying valuable releases 3. (Stretch) Building iterative software • Iterative/Incremental construction strategy • Planning for upcoming development
  13. 13. HI Per Lean Practice STORY MAPPING 203 Incremental Releases 1. Recap User Stories • Define • Usage 2. Planning valuable incremental releases • Identifying value • Identifying valuable releases 3. (Stretch) Building iterative software • Iterative/Incremental construction strategy • Planning for upcoming development
  14. 14. HI Per Lean Practice STORY MAPPING 203 Example Product:
 Mind Ink 1. Describing the product’s major features 2. Articulating the product’s depth 3. Deciding on value 4. Articulating on increments of valuable product
  15. 15. HI Per Lean Practice STORY MAPPING 203
  16. 16. HI Per Lean Practice STORY MAPPING 203
  17. 17. HI Per Lean Practice STORY MAPPING 203
  18. 18. HI Per Lean Practice STORY MAPPING 203 Spikes < Steel Threads < MVP Spike: the smallest throwaway implementation that demonstrates plausible technical success Steel thread: The set of stories required to drive out technical risks in integration
 MVP: The set of stories required to test a minimal proposition in the market
  19. 19. HI Per Lean Practice STORY MAPPING 203 Story Mapping Spikes
  20. 20. HI Per Lean Practice STORY MAPPING 203 Story Mapping MVP
  21. 21. HI Per Lean Practice STORY MAPPING 203 MVP Steel Thread The set of stories required to drive out technical risks is often not the same as the MVP Story Mapping
  22. 22. HI Per Lean Practice STORY MAPPING 203
  23. 23. HI Per Lean Practice STORY MAPPING 203
  24. 24. HI Per Lean Practice STORY MAPPING 203 Incremental Releases 1. Recap User Stories • Define • Usage 2. Planning valuable incremental releases • Identifying value • Identifying valuable releases 3. Building iterative software • Iterative/Incremental construction strategy • Planning for upcoming development
  25. 25. HI Per Lean Practice STORY MAPPING 203 Iterative Software 1. Recap User Stories • Define • Usage 2. Planning valuable incremental releases • Identifying value • Identifying valuable releases 3. (Stretch) Building iterative software • Iterative/Incremental construction strategy • Planning for upcoming development
  26. 26. HI Per Lean Practice STORY MAPPING 203 Sprint “Zero” What • Preparing the conditions for sprints • Team • Training • Dev Ops • CI & CD • Infrastructure • Spikes Why • Creates efficiency in delivery • Creates conditions to adhere to technical excellence • Affords the continuous removal of tech debt
  27. 27. HI Per Lean Practice STORY MAPPING 203 Definition of Done • complete articulation of what it means for a user story to be done • determines quality • owned by the Scrum team • can change - likely to differ between Scrum teams • creates alignment between scaled/dependent teams typical elements include: • meets all acceptance criteria • aligns to UX, architectural, DevOps guidelines etc. • any up/downstream Scrum team interface contracts met • design and code have been peer- reviewed • all automated tests pass • documentation complete
  28. 28. HI Per Lean Practice STORY MAPPING 203 PRODUCT OWNER ENVIRONMENTAL MARKET FORCES PRODUCT BACKLOG DELIVERY LEAD SPRINT BACKLOG PLANNING POKER STORY BOARDS BURN-DOWN CHART PLANNING PART 1 PLANNING PART 2 DAILY STAND-UP RETROSPECTIVE DEFINITION OF DONE SHOWCASE THE SPRINT GROOMING PRE-DELIVERY STAKEHOLDERS SCRUM TEAM
  29. 29. HI Per Lean Practice STORY MAPPING 203 The Sprint • relatively short time period (e.g. 1 to 4 weeks) in which a new working version of the product is created by delivering user stories • sprint length remains constant throughout an initiative • factors that determine sprint length: • change horizon • technical cycle time
  30. 30. HI Per Lean Practice STORY MAPPING 203 Sprint Planning Meeting • for planning the user stories to be delivered in a sprint • planning is a collaborative effort by the entire Scrum team • sprint planning meeting is in two parts: • what will be done • how it will be done
  31. 31. HI Per Lean Practice STORY MAPPING 203 Sprint Planning Meeting - Part 1 WHAT • Product Owner presents the Product Backlog to the Scrum team • starting from the top, the Scrum team selects the user stories it thinks it can deliver in the next sprint • these user stories form the sprint backlog, validated by velocity • user stories committed to should not be easily changed
  32. 32. HI Per Lean Practice STORY MAPPING 203 Sprint Planning Meeting - Part 2 HOW • Scrum team does any initial solution design work needed • Scrum team does an initial plan for delivering the sprint backlog • user stories are estimated in more detail • if there appears to be too much or too little work then the sprint backlog can be renegotiated with the Product Owner • other people can be invited to attend in order to provide domain or technical advice
  33. 33. RELEASE BURN-DOWN 1.0RELEASE 1.1 1.2 1.3 PRODUCT BACKLOG 1.4 FEATURE A COMPLETE FEATURE B COMPLETE A B C D E FEATURE C COMPLETE PREDICTED RELEASE OF ALL FEATURES
  34. 34. SCHEDULE SCOPE QUALITY BALANCING: SCOPE VS SCHEDULE Manage Delivery Add | Remove | Re-prioritise
  35. 35. HI Per Lean Practice STORY MAPPING 203 Iterative Software 1. Recap User Stories • Define • Usage 2. Planning valuable incremental releases • Identifying value • Identifying valuable releases 3. (Stretch) Building iterative software • Iterative/Incremental construction strategy • Planning for upcoming development
  36. 36. HI Per Lean Practice STORY MAPPING 203 Thank you!
  37. 37. HI Per Lean Practice STORY MAPPING 203 Acceptance Criteria
  38. 38. HI Per Lean Practice STORY MAPPING 203 Why User Stories + Acceptance Criteria? Documentation debt,
 source of defects, wasted development effort What was
 intended What was
 coded What was
 tested Wasted
 Testing
 Effort Over-documentation,
 missed requirements, source of scope creep Because the usual documentation processes produce this:
  39. 39. HI Per Lean Practice STORY MAPPING 203 Documentation code Development Sprint Planning Smoke Testing Test Validation Acceptance Testing Acceptance Criteria/
 Test Approach Product Management Portfolio
 Management Usage Executive Stakeholders + End Users Product Owners + Product Stakeholders Developers Functional Testing Product Owners Scrum Team Business Cases (Backlog Epics) Backlog + Wiki Structure Sprint Backlog +
 Wiki User Stories User Story:
 Testing Sections User Story:
 Technical Sections User Story:
 Delivery Decision Log User Story > JIRA link:
 Known Bugs/Issues Update Sprint User Stories >
 System Documentation System Documentation: User Guides Requests for changes, new scope, etc. Documentation TRADITIONAL DOCUMENTATION LIFECYCLE code
  40. 40. HI Per Lean Practice STORY MAPPING 203 Development Smoke Testing (against AC) Test Validation (against AC) Acceptance Testing (against AC) Portfolio
 Management Usage Executive Stakeholders + End Users Product Owners + Product Stakeholders Developers Functional Testing (against AC) Product Owners Scrum Team Business Cases (Backlog Epics) Backlog + Wiki Structure Sprint Backlog +
 Wiki User Stories User Story:
 Testing Sections User Story:
 Technical Sections User Story:
 Delivery Decision Log User Story > JIRA link:
 Known Bugs/Issues Update Sprint User Stories >
 System Documentation System Documentation: User Guides Requests for changes, new scope, etc. code IDEAL DOCUMENTATION LIFECYCLE User Stories User Stories Acceptance Criteria code Sprint Planning (detailed US + some AC) Acceptance Criteria Product Management (high level US)
  41. 41. HI Per Lean Practice STORY MAPPING 203 Intention = Code = Test Microsoft
 “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” Google
 “Pre-established standards or requirements a product or project must meet.” Federate the source of truth Federate the source of truth ACCEPTANCE CRITERIA

×