Agile Bootcamp #4 – Using Story Mapping to Teach Agile

User Story Mapping is a great technique to help teams explore their product scope and plan how they can deliver value to their customers as quickly as possible. Even for large and complex problems, teams can quickly create really useful User Story Maps. The technique was popularised by Jeff Patton and his excellent book, User Story Mapping.

As a coach, I also find that it helps me to understand the problem space and highlights where team members have different views of what they think the product is for. It gives technical teams comfort because it gives them permission to functionally decompose problems, but it also helps prevent that functional decomposition from ending up in their iterations by focusing on the horizontal slices being the releases.

The creation and discussion of the map also created numerous opportunities to dive into other fundamental agile and product design concepts.

I wanted to use User Story Mapping to help the team think about their release planning in terms of business value. I created a travel business example that let us explore different personas, splitting stories and identifying thin slices of value. This was a good example to use, as it allows the opportunity to consider non-IT-related elements of a solution that can decrease the time to market.

In this example, the overall business need was to be able to sell (or buy) holidays from a travel agent. The ambition is for an automated solution, but quite a lot of value could be delivered quickly with a simple web page and a telephone line for ordering and confirmations. This allowed us to have lots of conversations about trade-offs between quality, speed, revenue, branding, etc.

I also used it to talk about story splitting and the importance of decomposing goals into smaller goals rather than functional components. Different payment types, modes of travel, types of holiday, integrating services into the app vs linking to suppliers, and possible add-on services (like airport parking) were all rich sources of discussion and debate.
This example proved to be a very useful and engaging one, so I think I will develop it a bit further.

I designed it during the workshop just before the session after I changed my mind about developing an example live, so it would benefit from some rework!

Using manufactured examples is all very well, but I wanted to be able to focus on the team’s actual project. So, we spent the rest of the day focused on their product. So, we spent the rest of the final day focussed on their product.

This presented a problem. I knew I wanted to create a User Story Map and use that to derive a release plan (using the horizontal slices) that focussed on early delivery of value and iterative and incremental delivery.

However, the reason that we were there in the first place was that this project had been taken inhouse after previous problems with industry suppliers had led to a loss of trust. Over the past year or so, two different suppliers had already conducted large (and expensive) requirements capture exercises.

The nature of the product means that these requirements are probably not entirely wrong, and I was very cautious of being seen to be asking the team to do yet another requirements capture exercise (even if mine would take an hour or two, not six months).

I also wanted to avoid the situation where they are just restating existing features.

To overcome this, I went for transparency. I got a copy of the requirements so that I understood what had been done before and could give the team some confidence that I understood what they were trying to achieve. I have worked on similar systems before so I made sure that this came across to build up some credibility and trust.

Then, we used the Story Mapping approach to map out their value stream, identifying the activities and processes necessary to transform their input data into their results. Being able to refer to the existing requirements helped here, especially to prompt some of the alternate flows and exceptions.

Through this process, it became clear that the engineers had already been working on a prototype solution, so I decided to create a new map that just described what it already was able to do. This proved very helpful, as it quickly let us ask the question: “What is the minimum additional work required for the users to get some value from this system?” After a few rounds of challenge, where the minimum necessary was cut down even more (thanks to their enlightened Product Owner) and we had a description of our first version.

We then added on additional releases. In general terms, this system ingests various types of data, does some processing on it and allows users to conduct various types of analysis.

This meant that each new release had lots of choices:

• Should we add new types of data?
• Should we add new types or more depth to the processing?
• Should we add or improve the analysis?

This lends itself very well to iterative and incremental development, such as Scrum.

It also means that in input of the users becomes critical. Only once they are using the system and getting value from early releases can they honestly tell us what they would rather we focus on. So, we mapped out a few possible releases, but knew that they could (and almost certainly will) change.