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.

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.