O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

How to build shared understanding with example mapping

197 visualizações

Publicada em

One of the primary responsibilities of business analysts, product owners, and all other product people is to build and maintain a shared understanding of the outcome your team seeks to deliver. Conversations are an effective way to build that shared understanding.
You may find yourself wondering who should be included in those conversations, when do you have these conversations, what should you talk about, and how do you remember what you said?
Join Kent McDonald as he introduces example mapping, a technique that helps you structure your conversations and build a shared understanding.
You’ll learn how to determine the right people to include in your conversations, when the best time is to have those conversations, how to structure those conversations, and how to remember what you said.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

How to build shared understanding with example mapping

  1. 1. How to build shared understanding with example mapping Kent J. McDonald kent@kbp.media @kbpmedia https://www.kbp.media/go/sobarc-2019/ 1
  2. 2. Why talk about examples? 2
  3. 3. Why talk about examples? BUILD SHARED UNDERSTANDING OF THE STORY IDENTIFY AND ANSWER QUESTIONS TO MINIMIZE INTERUPTSDURING DELIVERY GIVE TEAM A JUMP START ON TEST PLANNING AND TESTING INVOLVE DIFFERENT PERSPECTIVES FOR A BETTER RESULT IDENTIFY AND DISCUSS ASSUMPTIONS PROVIDE CLEARPICTURE OFBUSINESS INTENT 3
  4. 4. Who should be included? 4
  5. 5. (At Least) Three Perspectives USER STORY DEVELOPMENT TESTING BUSINESS DO I HAVE ENOUGH INFO TO SOLVE THIS PROBLEM? HAVE I DESCRIBED THE PROBLEM I WANT SOLVED? WHAT HAPPENS WHEN… THE “THREE AMIGOS” 5
  6. 6. When should we have these conversations? 6
  7. 7. Just in Time BY END OF SPRINT N, HAVE ENOUGH STORIES DESCRIBED FOR SPRINT N+1 USER STORIES FLOW AS THEY ARE DESCRIBED (READY) 7
  8. 8. Discovery Board POLICY: USER STORY POLICY: • USER STORY • (SOME) ACCEPTANCE CRITERIA • SIZE POLICY: • USER STORY • ACCEPTANCE CRITERIA • SIZE • MOCKUPS • EXAMPLES • DEPENDENCIES • STAKEHOLDER POLICY: • USER STORY • (SOME) ACCEPTANCE CRITERIA 8 Getting things ready to rock is a great time for these conversations
  9. 9. How do we structure these conversations? 9
  10. 10. Example Mapping Outputs: § Examples § Refined rules/acceptance criteria § New/split stories § Shared understanding § Empathy 10 STORY RULE(ACCEPTANCECRITERIA) QUESTION (WHAT IF…) EXAMPLE(THE ONEWHERE…) https://speakerdeck.com/mattwynne/example-mapping Y R B G
  11. 11. STORY RULE RULE RULE QUESTION EXAMPLE RULE QUESTION EXAMPLE EXAMPLE EXAMPLE EXAMPLE Example Mapping 11
  12. 12. Add a Review Can only review sessions in own track Can only review a session once Can’t review your own session What if session changes tracks? What if reviewer is added to session as co- presenter? The one where session is in Reed’s track The one where session is not in Reed’s track The one where Reed is presenter The one where Reed is co- presenter Example Mapping – An Example 12
  13. 13. Your turn. In order to prevent passwords from being guessed, Users must be forced to create strong passwords 13
  14. 14. What do we use to remember what we said? 14
  15. 15. Collaborative Modeling 15 AS REED I CAN ADD A REVIEW TO A SESSION SO THAT I CAN PROVIDE FEEDBACK TO SAM
  16. 16. Sample Models PROCESS FLOW UI PROTOTYPE REPORT MOCKUP 16
  17. 17. Acceptance Criteria 17 § REVIEWERS MUST PROVIDE A TITLE AND DESCRIPTION FOR THE REVIEW. § REVIEWERS MAY INDICATE WHETHER THEY THINK THE SESSION SHOULD BE INCLUDED IN THE PROGRAM. § REVIEWERS MAY PROVIDE DETAILS OF ANY CONFLICTS OF INTEREST THEY HAVE IN REVIEWING THE SESSION. § REVIEWERS MAY PROVIDE COMMENTS FOR THE REVIEW COMMITTEE. § SUBMITTERS OF THE REVIEWED SESSION CAN SEE ONLY THE TITLE AND DESCRIPTION OF THE REVIEW. § SUBMITTERS MAY SEE ONLY REVIEWS OF SESSIONS THAT THEY HAVE SUBMITTED. § REVIEWERS MAY REVIEW ONLY SESSIONS SUBMITTED TO TRACKS ON WHICH THEY ARE REVIEWERS. § REVIEWERS MAY NOT REVIEW ANY SESSION ON WHICH THEY ARE PRESENTERS OR CO-PRESENTERS. § REVIEWERS MAY PROVIDE ONLY ONE REVIEW FOR A SESSION. § THE TITLE OF THE REVIEW MUST CONTAIN 95 CHARACTERS OR LESS. As Reed I can add a review to a session So that I can provide feedback to Sam
  18. 18. Examples 18 AS REED I CAN ADD A REVIEW TO A SESSION SO THAT I CAN PROVIDE FEEDBACK TO SAM Gherkin format is helpful to describe behavior of your product
  19. 19. Examples CALCULATE EVALUATIONS (SUM OF EVALUATION VALUES/COUNT) 19 Mocking up data in spreadsheets is helpful for calculations
  20. 20. Questions? 20
  21. 21. If you remember nothing else…. DISCUSSING EXAMPLES SPEEDS SHARED UNDERSTANDING DISCUSS EXAMPLES WHEN GETTINGSTORIES READY INVOLVE MULTIPLE PERSPECTIVES (THREE AMIGOS) USE MODELS, ACCEPTANCE CRITERIA, AND EXAMPLES 21
  22. 22. Kent McDonald kent@kbp.media @kbpmedia https://www.kbp.media/go/sobarc-2019/ 22

×