User Story Mapping - A try!

Note: The views in this blog are not the ultimate truth about User Story Mapping. This blog does not endorse Jeff Patton (but he is an awesome bloke). This is just the way we did it, and I do not/would not claim that this was perfect.

So after attending the Jeff Patton workshop on User Story Mapping at YOW! I was pumped to start using it. So when the opportunity arose I was keen to put it to use (of course our Delivery Manager was keen too). We had this relatively small MMF (Minimum Marketable Feature) come up which was a perfect candidate to introduce this concept to the team. Usually the User Story mapping would begin way before it reached the development team, but we had decided to use it as a tool to help us make the viable cuts.

Round 1: Map the story

In the initial phase we had a meeting to discuss the MMF which included the Development team, the Testers, UX, and Product management. The aim of the meeting was to understand what we were supposed to build and what functionality was required. We started off with a white board and some sticky notes and some sharpie’s.

The first thing that we did as a team was to write down the way the feature would flow. Or the steps that would be involved from start to finish when using the feature. Each one of us had about 11-15 sticky notes to define the feature. The number of sticky notes varied according to the level of detail each one of us described the process in.

Then as a team we put down the sticky notes in the order the feature would flow, if there were duplicates we just put them underneath the previous one. If a particular sticky note was just extra detail that would also go under the relevant column.

We now had a rough map of the way the feature works with some bits explored in details and some which lacked details.

Team trying their hand at User Story Mapping

Note: Its a good idea to use different colours for story mapping. We have started doing that for our next PBI. :)

Round 2: Divide and conquer

Round two was to go through all the sticky notes and see if we could find ones which sounded similar and grouped them if they conveyed the same meaning (story mapping makes you talk and discuss).

Next we all went through the sticky notes one more time, but the aim this time was to find and define a common underlying themes. To do this we scanned the map and tried to divide them into unique groups which conveyed the same idea. For example, the initial stages for the feature that we were working on all related to setting up the environment. This meant that we could group them into a common theme of Setting up.

The themes which came out of that made up our Spine for the feature.

Round 3: Personas and what they want

We have a set of personas which has been created for us by our UX team, they define different users that use our products and their knowledge about our products. As a team we also have a separate set of personas which define some of our internal organizational teams like Support, Business Systems, UX. We use these personas to further add details to the map by introducing stickies which if included in the product would make life easier for those personas. For example to make life easier for our Support team we would like to add extensive logging at every stage of the feature to make sure that it’s easier to debug. So added a new sticky for Logging on the map.

Our team personas (Our team name is Spice Girls and hence the names of the persons)

Adding extra information to the story map using personas makes it easier from an architectural point of view, as most of the details are given upfront making it easier to design the system. And also means less design changes need to be made at later stages.

Round 4: Viable cuts

The next thing that we did was to divide the stickies into viable cuts, Jeff Patton explains this with his Mona Lisa diagram and that’s what we used as our base. 

Mona Lisa - Source Jeff Patton's User Story Mapping

The viable cuts meant that we divided the features into horizontal groups such that the first group would create the basics of the feature, the second group would add some more details and so on and so forth.

While defining the viable cuts we made sure that the first cut would give us a working feature, then we would add some finer details to the feature in the second cut and so on. It would be taking an iterative approach.

Moving stickies to create Viable cuts

Round 5: Create Product Backlog Item's (PBI's)

The next thing to do after the viable cuts was rock breaking, which means dividing the viable cuts into smaller PBI's. This does not mean that the PBI cannot be divided further. This means that we have something to start our work with. If you add more details to the PBI, it would mean that you have a further discussion and might want to further divide the PBI into smaller PBI's. We try and divide our PBI's in such a way that any work started on the PBI should be able to be completed in 3 days time (this is a size constraint that we have set for ourselves, but not set in stone).

Round 6: Discussion does not stop

The work on the PBI's begin, but this does not mean the discussion stops. Its a continuous process and would probably continue even after the feature is completed.

UX and PO collaborating

This was a quick overview of our first experience with using User Story Mapping. As I mentioned previously this by no means is an accurate way of doing it, but you try and learn. I would be glad to hear how your experience with User Story mapping was and what did you do differently.