{"id":1009,"date":"2015-03-29T18:03:31","date_gmt":"2015-03-30T01:03:31","guid":{"rendered":"http:\/\/www.larrylawhead.com\/articles\/?p=1009"},"modified":"2017-10-24T16:57:21","modified_gmt":"2017-10-24T23:57:21","slug":"how-to-decompose-a-release-plan-2","status":"publish","type":"post","link":"https:\/\/www.larrylawhead.com\/articles\/2015\/03\/how-to-decompose-a-release-plan-2\/","title":{"rendered":"How to Decompose a Release Plan – User Story Mapping"},"content":{"rendered":"

A while back\u00a0my team overcommitted themselves on a\u00a0technical debt Sprint. It became apparent we did not have a decent model to expose those pesky “unknown – unknowns”. No matter how much talking and diagramming and more talking we did, we became none the wiser. We simply reached a point where we had to get started, and let the chips fall where they may. I struggled long and hard about this, until a fellow Scrum Master recommended Jeff Patton’s book, User Story Mapping. I’ll take the five steps mentioned in his book to explain how it helped us during a “high pressure” sprint. (One of those sprints where senior management all of a sudden remembers a promise they made.)<\/p>\n

Here are Jeff’s steps to User Story Mapping.<\/p>\n

    \n
  1. Write out the story a step at a time.<\/li>\n
  2. Organize the story from left to right.<\/li>\n
  3. Explore alternatives.<\/li>\n
  4. Distill your map into a “backbone”.<\/li>\n
  5. Slice out tasks that help your reach a specific outcome.<\/li>\n<\/ol>\n

    Here’s how we did it.<\/p>\n

      \n
    1. Gave every team member their own pile of post its. Then told them to write down everything we needed to do\u00a0to reach the goal,\u00a0from their perspective. I called this a “brain dump”.<\/li>\n
    2. Had each person place their post its horizontally along the wall as they explained how to get to the goal. After the last person told their story, we combined all the stories into a very long story (time line). Reading the story\u00a0aloud, we added new post its as team members brought up things we may have forgotten. We continued with this discussion until we were all in agreement as to the events and their sequence. (This part took a long time.)<\/li>\n
    3. Drew one long piece of blue masking tape above the story, and grouped the stories. We placed\u00a0the name of the\u00a0group above the blue tape.<\/li>\n
    4. Drew one long piece of blue masking tape below the groups\u00a0and placed everything that was not necessary for our initial effort \u00a0below the blue line.<\/li>\n
    5. Discussed who would take each post it and defined how\u00a0much effort they needed to complete it. This fostered further discussion ensuring the task and dependent\u00a0efforts were understood.<\/li>\n
    6. Entered all post its into JIRA using the standard Scrum story format with the definition of done defined during our discussion.\u00a0Assigned\u00a0the\u00a0story to the appropriate developer along with the effort estimate given during the meeting.<\/li>\n<\/ol>\n

      Here’s the\u00a0outcome.<\/p>\n

      We completed the first part of the executive’s promise. The sprint review was a success\u00a0receiving product owner sign off. Having worked through the complete story, we also understood what was required to fulfill the second part of the promise. The\u00a0team likewise\u00a0fell in love with user story mapping.\u00a0The dialogue fostered by story mapping, carries over into everyday problem solving discussions. Our team has never been so relaxed with each other and ready to hold focused problem solving discussions.<\/p>\n

      Here’s what we could do better.<\/p>\n

      Clearly user story mapping saved our necks. Comparing our experience with Jeff’s five steps, here is where I believe we could improve.<\/p>\n

        \n
      1. Write out the story a step at a time. – We did this pretty well.<\/li>\n
      2. Organize the story from left to right. – This presented no big problem.<\/li>\n
      3. Explore alternatives. – We could improve on this. While we were organizing the story, we discussed\u00a0a lot of alternate routs and stuff we forgot. We should have finished our first pass, then “opened the floor” for alternative paths, or filling\u00a0in things we forgot. Mixing steps one and two, caused some loss of focus.<\/li>\n
      4. Distill your map into a “backbone”. – This\u00a0was our weakest area. We tried to group the stories, but failed. Since we had so many steps on the wall and the team felt they had a\u00a0strong understanding\u00a0of the\u00a0individual pieces,\u00a0they\u00a0began loosing interest and we stopped.<\/li>\n
      5. Slice out tasks that help your reach a specific outcome. – This was rather magical, and the final confirmation we were on to something. During the story telling part, we easily identified things we could put in a later Sprint. These went below the blue line and were placed in our JIRA backlog. This kept us from having to search through meeting minutes or some extensive requirements document. Moving a post it below the blue line also required some additional\u00a0conversation and agreement.<\/li>\n<\/ol>\n

        Here’s what I’m going to do next.<\/p>\n

        I’ll review the book User Story Mapping again focusing on exploring alternatives and distilling the map into a backbone. I’ll also check some online resources. I’m a huge believer in this process. Every Scrum Master and Product Owner worth their salt, should read this book at least once.<\/p>\n

        Resources:<\/p>\n