A while back my team overcommitted themselves on a technical 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.)
Here are Jeff’s steps to User Story Mapping.
- Write out the story a step at a time.
- Organize the story from left to right.
- Explore alternatives.
- Distill your map into a “backbone”.
- Slice out tasks that help your reach a specific outcome.
Here’s how we did it.
- Gave every team member their own pile of post its. Then told them to write down everything we needed to do to reach the goal, from their perspective. I called this a “brain dump”.
- 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 aloud, 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.)
- Drew one long piece of blue masking tape above the story, and grouped the stories. We placed the name of the group above the blue tape.
- Drew one long piece of blue masking tape below the groups and placed everything that was not necessary for our initial effort below the blue line.
- Discussed who would take each post it and defined how much effort they needed to complete it. This fostered further discussion ensuring the task and dependent efforts were understood.
- Entered all post its into JIRA using the standard Scrum story format with the definition of done defined during our discussion. Assigned the story to the appropriate developer along with the effort estimate given during the meeting.
Here’s the outcome.
We completed the first part of the executive’s promise. The sprint review was a success receiving 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 team likewise fell in love with user story mapping. The 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.
Here’s what we could do better.
Clearly user story mapping saved our necks. Comparing our experience with Jeff’s five steps, here is where I believe we could improve.
- Write out the story a step at a time. – We did this pretty well.
- Organize the story from left to right. – This presented no big problem.
- Explore alternatives. – We could improve on this. While we were organizing the story, we discussed a lot of alternate routs and stuff we forgot. We should have finished our first pass, then “opened the floor” for alternative paths, or filling in things we forgot. Mixing steps one and two, caused some loss of focus.
- Distill your map into a “backbone”. – This was 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 strong understanding of the individual pieces, they began loosing interest and we stopped.
- 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 conversation and agreement.
Here’s what I’m going to do next.
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.
Resources: