In this post, we’ll discuss the preparation of a (series of) story mapping workshop(s).
The first challenge is putting together a team. Next, we need to make sure that the various team members each possess the correct mindset to start their research. It’s equally important that we limit the focus of the research and that we can make use of a wide variety of skills.
For optimal effect, it’s best that this modern agile technique is put into practice by a multidisciplinary team of which at least one person has a good amount of experience to help the team avoid common obstacles.
During the preparation phase of a user story map, we need to focus on four things: team, mindset, focus and skills.
Let’s have a detailed look at each of them.
The preparation of a user story mapping exercise starts with putting together a team. The team has to consist of representatives of various domains that represent the capabilities of the organization we’re creating the story map for. As such, in an ideal scenario, marketing, sales, accountancy, logistics, communication, ICT etc. all need to be represented.
For our team, we want to select people with all sorts of experience and that each have a network of colleagues to fall back on if necessary later on in the process. This implies a solid mix of younger and more experienced people and people with operational know-how as well as people with management experience.
Regardless of background, one of the most important skills is the ability to think beyond existing structures and to think customer-first. That’s why receptionists, call center agents and sales people can provide enormously valuable insights.
Process managers can deliver added value when they’ve got a good understanding of the processes across the various domains within the organization.
When an organization wants to introduce a (set of) new service(s), it’s best to expand the team to include people possessing the corresponding skills. By involving them straight away, we’ll undoubtedly improve the quality of the service we’re designing for and ultimately delivering.
(Note: the team can be presented on a domain/capability map. We can also apply the principle of value stream mapping.)
The size of the team depends on the scope of the research. Since it can grow in number the deeper we dive into the co-creation process, it’s wise to do the first story mapping exercise with a small team of internal employees. Once the team has learned enough and sufficient trust has been built, we can expand the team to involve clients and partners.
Our objective is to design customer-oriented services. This is something best achieved when our team members possess an outside-in mindset, which can be ‘developed’ by having them research the eco-system the organization is part of.
As a team, it’s important to gain insight into our current customer experience, because it’s in that journey that we’ll be placing our new services. By way of these insights, we’ll be able to precisely tune our services to the needs of our customers.
Once we realize/affirm that our customer population shares certain characteristics but in essence is diverse in nature, we can hold this into account when we (re)design a service. Creating a (few) persona(s) helps the team to keep the customer’s perspective front and center. If the organization has a good direct contact with certain customers, we may add these to the team. But it’s up to the organization to decide in which part of the project we’ll want to involve them.
Quite often, we deliver services in association with partners and with competing organizations in mind. This means that our customer experience is affected by the way we work together with our partners and by the way in which our service relates to competing alternatives. Therefore, it’s wise to create a model that visualizes the network of partners and competitors because it will increase our understanding of the value stream.
Again, it may be necessary to expand the team at this point if the outcome of our research warrants it.
As soon as the team has a sound enough understanding of the organization’s surrounding eco-system and after it’s been expanded to include customers and/or partners, its focus can be minimized by selecting a number of personas and touchpoints in the customer journey(s).
The team can determine the scope of the story mapping exercise and formulate hypotheses based on these personas, services (within the context of the selected journeys) as well as on the cooperation with partners.
Here’s how we can formulate each of our hypotheses:
Because <<we (re)design new/existing service x together with partner x for personas x,y,z>>
We might <<trigger a certain reaction>>
Which will lead to <<a certain outcome>>
Together, they’ll create a framework in which customer needs can be discussed, questioned and verified.
The various team members will learn how to describe all of their (functional) needs in the form of user stories. User stories are a very intuitive technique that is easy to take up and uses the following fixed format:
As a <<persona x>>
I want to <<do something (task, app)>>
So that <<goal is reached>>
In a future post, we’ll discuss the creation of a first story map as well as the calibration of user stories.
The next step is to determine the acceptation criteria, which is just as important as describing the (functional) needs. These are best written down in the following format (we’ll go into these in more detail in a future post):
Given <<some context>>
When <<some action is carried out>>
Then <<a particular set of observable consequences should obtain>>
It’s best that a few members of the team have the skills to illustrate the user stories we’ve determined. A commonly used app for doing so is balsamiq.
Classic business and application architecture techniques (information model, status diagram, components model) can also come in handy when the team wants to examine the impact of the service’s implementation.
- It’s highly important to invest in a multi-disciplinary team: from people working in various domains within the organization to representatives of external parties, most notably customers and partners.
- The team can then tackle the research with the proper mindset and keep the focus on the customer’s experience without losing track of the experiences of employees and partners.
- The team needs a solid understanding of the eco-system in which the organization delivers its services.
- Make sure to formulate clear hypotheses before starting to (re)design (existing) services.
Want to get your team trained in writing user stories and coached by a facilitator to get your user story mapping workshops started? Get in touch.