Picking our slice

(Part 2 of 2)

As we were unable to finish the story-mapping process in a single session, we had a second session the following day. As prep and to save time, I asked the team to bring their top six user stories written on separate stickies. Following the approach outlined in the video, we grouped and prioritised their top stories and then I asked the team to pick their overall top five. At this point I also introduced the concept of tarred vs cobblestoned vs dirt roads (stories):

• A dirt road is minimum implementation with manual workarounds; something that will be in place for a limited time span (throwaway)
• A cobblestone road is a bare minimum implementation with foundations for a longer term solution
• A tarred road is a complete implementation: a ‘done done’ story

Cobblestone and dirt road stories were written on an orange sticky, while tarred road stories were yellow. Even with this mechanism, the team were not able to get their first slice down to less than seven tarred stories – which was still great going 🙂 With our first slice agreed and our pink risks/issues added to the appropriate place on the map, we had just enough time to do a bucket estimation exercise. For this, I laid a set of planning poker cards on the floor to create buckets; picked a story as a baseline (I chose one we’d already implemented for more context); and then everyone had to add stories to the buckets according to where they thought they should go relative to the baseline. This is a mostly silent exercise. For the first part each person is given a random pile of stories to place into buckets. For the second part, everyone reviews and (silently) moves stickies to different buckets if they disagree with where they have been placed. If a stickie moves a lot, it is parked. When the stickies stop moving and stabilise in their buckets, then the parked stories are discussed to understand why there are differences in opinion and the team should then reach consensus on which bucket each parked story belongs to. We didn’t have to do this last part as everyone was more or less on the same page about where things belonged.

As an aside, after we’d created our map, I reviewed our completed work and added those stories into it as well. We will be tracking progress on our map as we go. It is recommended practice to write duplicate stickies for your taskboard and not leave gaps in your map. I can see this also making sense where a ‘map story’ may need to be broken down into smaller stories for sprint purposes (if your team is using Scrum). For us, a map story that is in progress gets a dot (sticker) and, once it’s done, we tick the dot. It’s visual and easy to follow.

After a total of three-and-a-half hours we had the following:

1. A better understanding of the short-term and long-term goals of the project.
2. A ‘first slice’ to test our architecture, resolve some technical challenges, and deliver some business value in production.
3. A first pass idea of the size of the full scope of work.
4. A picture view of all the above with a visual way of showing progress against the overall scope.

Things that I felt worked well in the second session:

• As we don’t have a team room (so were using a shared meeting room), I did have a challenge with the session being split over two days as I needed a quick way to reproduce the map for the team for the second session. In the end, I took photos of the various sections and printed them out in colour and that was enough for the team to refer back to (helped by the fact that they had all rewritten their top six stories on stickies for the second session anyway).
• The road analogy helped create a common understanding of the level of work we were targeting and using a different colour to represent work that was not ‘tarred’ made it clear where we would have to revisit items to fully complete the story.
• Giving people a very strict limit initially. I doubt we would have ended up with a slice of seven stories had I not been so strict about trying to get the team to only pick five.
• The sizing exercise got people off their feet and moving around (automatically creates more energy).
• The sizing exercise took all of 15 minutes, so high value for small time investment.

Things that didn’t work well:

• Some of the team members were unable to attend the second session. We decided to go ahead anyway, but this did impact the perceived value and accuracy of the sizes.
• The team haven’t taken ownership of the story map (still perceived as ‘my thing’). Need to find a way to change that perception!

Links

• Part 1
• More detail on bucket estimation
• This article describes two techniques: Affinity Estimation and Bucket Estimation. I’ve used both before and I so far have found bucket estimation is quicker so better for large backlogs (value:time ratio for affinity estimation doesn’t seem as good).
• Affinity Estimation How-to