Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Why your product team should use User Story Mapping to link user research to user stories

2.552 visualizaciones

Publicado el

How well do you think your product team takes what they learn from their users and puts it into the next iteration of the product? How well does your team come to a common understanding of what the next iteration of the product will look like and then build a product that reflects that common understanding?

These two problems — improving your product with user research and effective team collaboration — can both be solved with a design tool called User Story Mapping.

In this session, attendees will hear how to apply User Story Mapping to connect user research to user stories for Design Thinking and Agile Development and the experience our teams have with the method. Attendees will get a taste of going through running a simple user story mapping workshop so that they will feel comfortable taking the process back to their business.

  • my neighbor's mother makes $64 hourly on the laptop. She has been out of work for five months but last month her payment was $15080 just working on the laptop for a few hours. Go to this web site and read more....Gold.jobs89.com
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Why your product team should use User Story Mapping to link user research to user stories

  1. 1. Linking user research to user stories with user story mapping
  2. 2. I am John Murray Design Lead, IBM Hybrid Cloud Developer Experience Hello!
  3. 3. ● Design lead at IBM, 3 years ● Design leadership, 5 years ● Designer, 10 years ● IBM & AIGA design thinking facilitator About Me
  4. 4. The handoff Design thinking to agile implementation should be a smooth transition, but when it doesn’t go well it can be problematic for everyone involved.
  5. 5. How design thinking should be
  6. 6. How it often turns out
  7. 7. The divide
  8. 8. I noticed that design thinking workshops made product teams think they were on the same page until it was time to get granular.
  9. 9. The good vibes and sense of alignment turned to uncertainty about how to get to market.
  10. 10. “ Uncertainty turned to inactivity We have mission statements for our release (hills) … now what? We have hills … how do we act on them? We have user research … how do we use it to impact the product?
  11. 11. “ Let’s not try to break this stuff down now. We’ll figure it out as we go! Inactivity turned into teams saying …
  12. 12. Product teams need a way to bridge the divide. User Story Mapping YOU
  13. 13. User story mapping … explained in actionvisualized
  14. 14. User story mapping explained User story mapping takes a measured approach to decomposing design thinking hills. At its core, we break down hills by simply asking ourselves, “what does the user need to do to get this done?”
  15. 15. User story mapping visualized ◉ Represented as a tree ◉ Starts with an overarching vision ◉ Can be broken into corresponding agile components
  16. 16. achieved by accomplishing goals. broken down into agile stories. completed by performing tasks. reached by completing activities. smallest increment of the process.
  17. 17. Goal Activity Tasks Stories Vision Our online customers need an easier way to search through our inventory and find the item they’re looking to buy.
  18. 18. User story mapping in action We’ve been working with Hybrid Cloud product teams to implement user story mapping. The Continuous Release and Delivery Insights teams were kind enough to work with us. Examples today will come from our work with them.
  19. 19. Delivery Insights As-Is ◉ Customers asking for features for different use cases ◉ Lack of direction from previously written hills ◉ Design was building what dev said customers needed
  20. 20. The benefits User story mapping has a lot to offer product teams that invest the time.
  21. 21. User story mapping benefits ◉ Visual presentation of your backlog ◉ High-level view of work being done in the current release ◉ Improved collaboration between stakeholders
  22. 22. User story mapping benefits ◉ Prioritized work based on collaborative goals ◉ More accurate story sizing ◉ Simplification of product road map ◉ User stories become developer work items ◉ Iterative collaboration process
  23. 23. The process Here’s how to run a user story mapping workshop session with your team.
  24. 24. User story mapping phases pre-work post-workduring
  25. 25. Pre-workshop homework Know the stakeholders Reach out to key stakeholders before the session. Explain the purpose of the exercise. This generate advocates who come in ready to participate. Know your user If you can get feedback beforehand from users. Do it! If you need to build a persona, then come in with one that’s been validated ahead of time. Know the user’s experience Map out the current user experience. What’s the as-is? You can’t make life better for your user if you don’t know their pain points . Know what you want to do for them You know the user. You know their pain points. Now how are you going to make things better for your user? Create a draft of hills that summarize the who, what, and wow you plan to provide.
  26. 26. Know the stakeholders ◉ Researcher / design lead ◉ Product manager ◉ Development lead Min. required stakeholders Meeting topics ◉ Introduce the topic and explain the use and benefits ◉ Spend 15-20 minutes building a user story map
  27. 27. Delivery Insights’ persona
  28. 28. Created by Delivery Insights after they realized they weren’t focus on the right user. Delivery Insights’ As-Is
  29. 29. Delivery Insights’ draft hills
  30. 30. During the workshop Revisit pre-workshop hills Before you do anything align on the hills you wrote beforehand in case not everyone has seen them. First draft of to-be scenario If the as-is tells us what the user’s experience is like now, the to-be tells us what it will be like after we deliver on our hill or mission statement. Refine workshop hills At this point we ask ourselves, “knowing what we know about the to-be we created, do we need to revise the language of the hills?” Second pass at to-be scenario If we’ve revised the language of our hills, we need to reflect those changes in the to-be scenario. Refine hills one last time Now that we feel confident about our to-be scenario, let’s do our best to finalize our hills before moving on. Draft of Golden Thread The purpose of the Golden Thread is to prioritize what development will deliver first, with the specific intent that research will validate it with the user after the workshop.
  31. 31. Revisit pre-workshop hills Before After
  32. 32. First draft of to-be scenario
  33. 33. Before After Refine workshop hills
  34. 34. Second pass at to-be scenario
  35. 35. By the end, one hill became two separate hills. Before After Refine hills one last time
  36. 36. Draft of Golden Thread
  37. 37. Post-workshop follow up Validate the Golden Thread Up until now your scenario is a hypothesis. Put it in front of sponsor users for validation. Team finalizes hills, epics, & user stories Clean up the language on any unresolved hills, epics or user stories. Add finalized work to product backlog Start to create work items in the backlog that reflect the Golden Thread.
  38. 38. Validate the Golden Thread
  39. 39. Add finalized work to product backlog
  40. 40. Stakeholder Feedback
  41. 41. “ “It was a breath of fresh air.” Q: How was the user story mapping experience?
  42. 42. “ “We kept iterating on the same thing over and over until we narrowed in on what was really good about it. That refinement was really big for us.” Q: What did you get most out of the process?
  43. 43. “ “I liked the idea of creating the Golden Thread where—one, you pull out the high priority items, and two, you tell the story all the way through.
  44. 44. “ “We end up passing high level information from one person to the next then back to customers … We understand everything from high level value to what it takes to implement, and everyone’s on the same page.” Q: How have things changed since the workshop?
  45. 45. Dos & Donts Learn from our mistakes by remembering these key takeaways.
  46. 46. ◉ Don’t allow unvalidated personas from any stakeholder. ◉ Do your user research. Your success depends on it! ◉ Do get a facilitator. You need to focus on helping your team. ◉ Don’t worry about perfection.
  47. 47. Fitting it together Let’s take a step back and see how this fits into a continuous delivery process.
  48. 48. If you have any questions … @heyjohnmurray On Medium, Twitter, and LinkedIn Thanks!

×