User Story Mapping - Collaboration secrets

I am writing (or planning to write) a series of blog posts to share my learning's from the User Story mapping workshop at YOW 2014 with Jeff Patton.
User story mapping is a technique used to provide a holistic view of the project and gain shared understanding. There is (obviously) more to it, you can check out Jeff Patton's work on it or read one of the blog's on how we did it here.

Collaboration Secrets:

Collaboration when done correctly can yield results which individuals would fail to achieve. It is an integral part of working as a team. So there is no doubt that collaboration is a key to developing a good story map and also for developing shared understanding. During the workshop Jeff introduced us to some secrets for healthy collaboration. Though they might seem obvious they are at times forgotten to difficult to implement. Lets have a look at each of them:

Secret 1: Shut Up!

This seems a little odd when the whole point of collaboration is to talk and share ideas. But according to Jeff the less you say the more you listen and hence more you understand. The key is to know when to shut up and let someone else share their thoughts. Listening to others also helps in Shared Understanding as this helps you clarify if everyone is on the same page.

Secret 2: Fewer people, works!

While creating user story maps its essential to work with fewer people or smaller groups. That does not mean that the rest of the team should feel left out of the process. There can be multiple sessions with a smaller group rather than having a board room discussion with 15 people. As a ball park, its good to work with a team of 3 to 5 people.
Having less people means less chaos and everyone gets a chance to have their say. The smaller groups can be strategically formed to have an input from different teams or from people with different skill sets.

Secret 3: Move Fast!

When doing User story mapping its essential to know that we aren't building the ultimate story map which once created cannot be altered. Hence its OK to miss out on details cause we will have time to do it at the later stage if needed. The idea is to get sufficient details with which you can work! The next point helps with moving fast.

Secret 4: Time box

Time is of essence in most situations and its no different when it comes to collaboration. Hence its a no-brainer that time boxing is a key secret to collaborating. Each round of User Story mapping is time boxed which helps to keep discussion from going astray. We need to have sufficient information which gives satisfying (good enough) level of detail. Before starting any round decide on the time for how long should it go for and then stick to it. This will also mean disciplining everyone to only talk about relevant topics and park the rest on for later if there is time.
The fast paced approach also keeps everyone active (this was my observation from the workshop)

If you have any cool collaboration tips so share.

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.