schedule Mar 16th 11:30 AM - 12:15 PM place Esquire

One common problem any delivery team struggles is to have a common understanding of "why" a product or feature is being built. The documents such as Project Charter, vision document etc. tries to solve this problem, but it’s common to see such documents exist in the repository, hardly known or read by anyone in the team. And this document rarely gets updated too. Ask your team members what is the goal of the project? You may be surprised to know how many actually know about it.

The so called "vision" or "goal" usually rests within Product Manager/Owner or any other stakeholder. There is no forum to converse about these goals or ideas as a team. The planning meetings [iteration or release planning] are supposed to take care of this, but there is no standard guidelines defined which would help to brainstorm these in a typical release/iteration planning meetings.

This is where Impact Mapping comes into the picture. It is a "Strategic planning technique", defined by Gojko Azdic, explained in the book Impact Mapping. It is a very simple technique based on the idea of "asking the right questions" which are:

  • Why are we building what we are building? i.e., Goal(s) of the product
  • Who we think are the actors who’ll get impacted?
  • How do we expect to change the actors’ behavior?
  • What are we going to do to create the impacts? i.e. the feature list / deliverables

Finally, by connecting the deliverables to impacts and goals, a map shows a chain of reasons that leads to feature suggestion. 

Fundamental of Impact Mapping is that Impact means a change in behavior of an actor which usually results in a positive impact either by Reduction in the Cost or Improvement in ROI for the business.

If you closely watch the sections in Impact Mapping, what to build i.e. the features or the so called backlog comes only at the end, whereas in the typical planning meeting we usually start with a backlog.

The above questions need to be answered by the entire team [the IT team, the business people and any other stakeholders, if any], and avoids the common anti-patterns during planning meetings:

  • Ad-hoc planning
  • Wrong Assumptions
  • Pet features

The hands on workshop will cover the above mentioned concepts of Impact Mapping in detail along with exercising the same.

Below are a few comments that we received from our customers after being part of the Impact Mapping session:

  • “It made me think about the real goals my product has to achieve during the initial launch.”
  • “Wow, this is a great way of visualizing”
 
5 favorite thumb_down thumb_up 8 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

The session will cover:

  • Problems is in the typical "planning" sessions - 5 minutes
  • Overview of Impact mapping - 15 minutes
  • Exaplaining the real "Case study" of Impact Map  - 15 minutes
  • Summary and Next steps - 5 minutes
  • Q&A - 5 minutes

Learning Outcome

At the end of this workshop, the audience walks out with:

  • A Clear Understanding of “Impact mapping”
  • A "flight simulation" of a typical Impact mapping session
  • First steps towards implementing the same.

Target Audience

Product managers, Architects, Product Owners, Business Analysts

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Tathagat Varma
    By Tathagat Varma  ~  2 years ago
    reply Reply

    Leena - we think it will be good to present some real-world example or a case study of why and how you implemented impact maps, and what was the result. So, maybe a shorter session based on some hands-on work along with case study for practitioners? Can you revert back on it?

    • Leena S N
      By Leena S N  ~  2 years ago
      reply Reply

      Hi TV,

      Are you suggesting that the session should contain both case study and a hands on session [which is what I had proposed already] to be done in a shorter session? I believe I didn't understand you correctly.

      BTW, I shared this proposal structure in the Impact Mapping group and got the below response from the group [from Lisa Crispin to be precise] i.e.

       

      Hi Leena,

      That's an outstanding proposal! So well organized, you covered the problems that impact mapping addresses, you showed how you will use the time, you included learning outcomes. I hope that gets on the program, it will be an excellent learning experience!

       

      You can see the same in the below link too, but its available only to the members.

      https://groups.google.com/forum/#!topic/impact-consultants/W65a2Bbfw5Y

      Thanks,

       

      • Tathagat Varma
        By Tathagat Varma  ~  2 years ago
        reply Reply

        Leena - we were wondering if a 45min case study will create more value than a 90min workshop. Would you be able to present a case study that allows the practitioner to understand what is impact mapping and how it was deployed in a real-world problem and what problem did it solve?

        • Leena S N
          By Leena S N  ~  2 years ago
          reply Reply

          TV,

          I've updated the details to reflect for 45 minute talk. I am not able to remove the tags related to workshop i.e. 90 minutes and workshop. Hope thats fine.

           

  • Naresh Jain
    By Naresh Jain  ~  2 years ago
    reply Reply

    Hi Leena,

    Just wondering how is this different from Story Maps?

    Also can you please point me to a blog/article where I can learn more about your insights around using Impact Map technique?

    • Leena S N
      By Leena S N  ~  2 years ago
      reply Reply

      Naresh,

      I hope you are referring to Story Maps mentioned by Jeff Patton. AFAIK, story map talks about the user journey or user actions for achieving a specific task in the product. Needless to say Story Map is great too to understand the complexity of the feature/functionality and also helps to bring in shared understanding.

      Impact maps come much earlier than that, by asking "why" of the feature and also helps to understand what Impact, behavior change, it brings in to the end user which also results in a business impact. A good example can be "Implement Facebook Share or Invite feature to reach 1 million users", 1 million users is the business goal and Invite feature is one way to achieve the same.

      You can use Story maps along with Impact Maps i.e. for eg: how to implement Invite feature can be explained using Story maps. We've used Impact Maps along with Design sprint [http://www.gv.com/sprint/], which has worked very beautifully to bring in shared understanding and also for describing the user journeys.

      Hope I answered your question.

      I've updated the blog that Karthik [co-speaker] has written about Impact Mapping in the links section.

      Thanks,

      Leena

       

  • Raja Nagendra Kumar
    By Raja Nagendra Kumar  ~  2 years ago
    reply Reply

    It would nice to talk about corporate greed (to scale team) and politics (to create noise and win in confusion). When systems intent is wrong, nothing can be correct..which would be known at last mile only..

     

    • Leena S N
      By Leena S N  ~  2 years ago
      reply Reply

      Hi Raja,

      Not sure whether we can cover that in detail because thats *complicated* subject by itself. Hope we can cover these during the Q&A sessions. 

       

      Thanks,

      Leena

       


  • Liked Sudipta Lahiri
    keyboard_arrow_down

    Sudipta Lahiri - Continuous Improvement with Toyota Kata

    20 Mins
    Talk
    Intermediate

    Most Lean/Agile team have had limited success in establishing a culture of Continuous Improvement. Retrospectives are done but in most cases they are done without a goal, a vision. Toyota Kata, as codified by Mike Rother, is an approach to put an culture of Continuous Improvement in a team/organization.

  • James Shore
    James Shore
    Consultant
    Titanium I.T. LLC
    schedule 2 years ago
    Sold Out!
    480 Mins
    Tutorial
    Intermediate

    This full-day workshop focuses on applying Agile engineering practices to web development. We'll look at practices such as build automation, continuous integration, test-driven development, refactoring, and incremental design and see how to apply them to front-end web development. We'll cover topics such as cross-browser testing, JavaScript, and CSS.

    Audience: This session assumes familiarity with Agile engineering practices such as test-driven development and refactoring. Experience with JavaScript, CSS, and other web technologies is recommended. Come prepared to code.

  • Liked Manish Chiniwalar
    keyboard_arrow_down

    Manish Chiniwalar - Workshop on Design Sprint - Concept to Confidence in less than 5 days

    960 Mins
    Workshop
    Intermediate

    How fast can you go from an Idea to Reality?

    From an idea to the time you validate your solution with real users - not friends and family, how long does it take?
    In case you are yet to start, how long should you take?

    Lean Startup is a buzz-word these days. And for a good reason too - it works! But, there may be times when you get hung-up trying to validate with methods like landing pages, MVPs, MVFs and Interviews. And before you know it, a month has passed by, trying to generate traffic to your landing pages, making sense of analytics and polishing your MVP. 

    The Google Ventures' Design Sprint is a framework for solving real-world problems through research, ideation, prototyping and talking to real users, in 5 days or less.

    How will Design Sprint help?

    • Focus. First off, design sprint will put you on the clock. 3-5 days of complete immersion. 
    • Build the right thing. Taking a Design Thinking approach inspired by IDEO, will help you look at the problem the way your customer would. Then user your teams creativity to solve it in unique ways. 
    • See the Truth. When you'll put the prototype to test in the hands of a real user, your team will see first-hand what works and what doesn't. It's the next best thing to reading your customer's minds.
    • With a couple of days still left in the week, you relax with a cup of Earl Grey tea and do some more thinking. Probably, get ready for the next sprint.

     

    When we conducted design sprints with our customers, we had some unexpected realizations:

    • We saw that the ownership and motivation in the team improved significantly.
      They were mindful about "why" they were working on the features they were working on.
    • Our customers would say, "This has completely changed the way I think about building products." 
      Going from a solution driven approach to problem-first approach and keeping the products very lean.

     

  • Liked Neil Killick
    keyboard_arrow_down

    Neil Killick - The Slicing Heuristic - A #NoEstimates Method for Defining, Splitting, Measuring and Predicting Work

    Neil Killick
    Neil Killick
    Lead Agile Coach
    MYOB
    schedule 2 years ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    This is a concept I devised a couple of years ago, and it seems there is a new #NoEstimates audience that would like to know more about it.

    A Slicing Heuristic is essentially:

    An explicit policy that describes how to "slice" work Just-In-Time to help us create consistency, a shared language for work and better predictability.

    The Slicing Heuristic seeks to replace deterministic estimation rituals by incorporating empirical measurement of actual cycle times for the various types of work in your software delivery lifecycle.

    It is based on the hypothesis that empiricism leads to smaller cycle time duration and variation (which in business value terms means quicker time to market and better predictability) because it requires work to be sliced into clear, simple, unambiguous goals. Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require.

    Its application is most effective when used for all levels of work, but can certainly be used for individual work types. For example, a User Story heuristic can be an extremely effective way of creating smaller, simpler work increments, allowing teams to provide empirical forecasts without the need for estimating how long individual stories will take. However, if you are able to incorporate this concept from the portfolio level down, the idea is that you define each work type (e.g. Program, Project, Feature, User Story, etc.) along with a Slicing Heuristic, which forms part of that work type’s Definition of Ready.

    This talk will equip teams and organisations who are established on their Agile journey with a robust, clear and repeatable method for improving the quality and time-to-market of their software development efforts.