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.

Risk Radar - How we did it!

Disclaimer - This is just how we did it. Does not mean its right! I will write a separate blog to let you guys know how this Risk Radar is working for us.

A bit of a preface:

At the start of this week our Delivery Manager (DM) sent us an email and announced that we need a Risk Radar for our team. He had done his research on Google and decided the general image that he wanted to go with (or rather choose the first image that came up for Risk Radar on Google). He also setup a meeting with the team to discuss this further.

A few questions that were raised and how did we deal with them:

Why do we need a Risk Radar?

As a team why did we need a Risk Radar? We already had a Kanban board to show what the team was doing. So what risks would the Risk Radar show? After our brief meeting we decided on a few risks that would affect out team. And this was the first time we were making it verbal and putting it on the Risk Radar, so something would have to be done about it. We had to make sure that we mitigate the risk.

Who was it for?

So did we need a Risk Radar to show us the risks that "WE" came up with? Or was this Radar more for someone outside the team to have a look at and instantly know what were the risks that we as a team faced.
The answer to that was, the Risk Radar was for everyone. It was for the team to know what Risks they would face and then find ways to mitigate them and get them to a point where they no longer are a risk. Anyone outside the team, the Radar would give a high level view of the Risks that the team had. Making it visible to the others (outside the team) would mean that we are keeping it transparent and also allowing a discussion (and a potential solution) to solve or address the risk.

What does it show?

So once we decided who is the risk radar for, now we wanted to know what would be shown on the Risk radar. There are quite a few different ways in which you can name and use your risk radar axis and quadrants.
The method we implemented to come up with our quadrants and axis was "good old discussion". Our DM had made up his mind that he wanted the risk radar to show Probability and Impact of the risk. After our initial discussions we decided to add the Time factor in as well. So the Risk Radar would show what risk we had, what impact did it have on our team and the probability that the risk would happen. It would also show the time frame for the risk. We settles on having a "4 week", "8 week" and "8 week and beyond"time frames which can be seen in our final Risk Radar diagram below.

Now we wanted to decide what the quadrants meant. And what the Axis would represent. A few options for the quadrants where:

Technical and non technical
Outside team and within team

Making a decision for this was a bit tricky, we had to come up with something that could classify all the risks that we put up on the radar. So we came up with a few risks that we faced as a team and then tried classifying them into the right quadrants. After analyzing a few risks we figured out that the Outside team and within team options for the quadrants fir perfectly well. The Axis was fixed to Origin and Mitigation. So our quadrants now look something like this:

First Quadrant: Risk originated outside the team, which needs to be mitigated by the team
Second Quadrant: Risk originated within the team, which will be mitigated within the team
Third Quadrant: Risk originated outside the team , which will be mitigated externally
Fourth Quadrant: Risk originated within the team, but will be mitigated externally.

Visualization:

Our team is very pro-visualization. So our next point for discussion was how do we visually show the probability and the impact. A few ideas that were tossed were:

• Coloured post-it's
• Different coloured dots to represent impact on coloured post-it's
• Different shapes of post-it's to show impact combined with different colours
• Coloured post-it and different sizes

After a lot of discussion and a lot of different options we settled on having different colour post-it's to show the Impact and 3 different sizes to show the probability.

So our current Risk Radar looks something like this:

Risk Radar

This is work in progress, we will see how this suits us. I will write a separate post if we make any changes.