User Story Mapping for Domain Discovery
Learn what User Story Mapping is and what it can be used for, including domain discovery and design.
Are you in a company that are customer obsessed, striving to create solutions that focuses the user needs and desires? Maybe you even try to build those solutions together with the customer, involving them in the actual design by building incrementally using mock-ups, pilots, and MVPs? Or, maybe you are not there yet, but want to be? Anyhow, you have probably then wondered how on earth you can design and build a viable systems portfolio in such a setting, avoiding the risk of stringing together unfinished components with duct tape, strings and paper clips, or creating overly complex solutions to cater for any future need. There is a lot of talk about evolutionary architecture, but how can we tie that in with the customer needs? In order to build sustainable systems we need to know where the early prototypes are taking us; we need to be able to see further ahead. In short, what can help us do domain discovery in this agile world?
In this workshop, we will take a close look at a technique that came out of the agile community, user story mapping. The original application was to get control of the product backlog, making it explicitly connected with the user interaction and help discovering delivery slices that are viable for the user. Its applicability can also be extended to include other phases of the product delivery, all the way from the initial ideas and inception, creating coherent customer journeys, to the continuous enrichment and maintenance of the product after the initial deliveries.
We will create a map for a concrete product taken from the pay TV domain, trying to follow all the phases of the product delivery and discover the intricacies of the domain along the way. The user need is the main driver here, but will also be constrained by company strategies, IT legacy, organisational structure, and many other factors. We will then try to create a domain model that not only cater for the initial needs, but also what the map is telling us about the future. The goal is the balancing act of supporting the initial version well, not creating an overly-complex model that caters too much for possible future need, but still being adaptive enough to absorb changes that we see coming.
No programming skills required, but having IT experience is. Also, some experience with user stories and agile methodologies is advantageous, but not required. Should be relevant for anyone in a product team, i.e. product managers, service designers, UX, testers, business analyst, architect, and programmers. Some experience with modelling and creating diagrams (UML/C4) is useful. You also need to enjoy a collaborative environment, where all voices is heard.
Benefits of participating
The participants will gain insight of user story mapping and its applicability in the development, delivery, and maintenance of a product, as well as using it as a tool for domain discovery and design. The participants will do some modelling and will be exposed to the C4 model.
Paper rolls, post-it notes, and pens.
The intention is to make this a highly collaborative session, where we learn by doing.
The group will be split into smaller teams of 5-6 people each which will work together throughout the session.
Short presentations will be given on the techniques and the case under study, but the intent is also to share ideas from the participants. There is no one right way of approaching this.
In the first half of the session the teams will create a story map based on the requirements given and the session leader will act as the domain expert.
In the second half we will share modelling techniques and the teams will try to model the domain based on the knowledge from the story map and other requirements gathered from the domain expert.
The teams will also have to update their map and model based on new requirements.
The session will conclude with the teams sharing their maps, models, and experiences with the rest, hopefully getting a discussion of how this user centred approach worked for domain discovery and modelling.
Describing the intention of the workshop
Presenting basic story mapping
Presenting the case from the pay TV domain
Mapping in teams based on a user need taken from the pay TV domain
Presenting story slicing and creating product increments
The teams slice their story map based on product priorities
Short discussion on modelling techniques
The teams models the domain, e.g using system context diagrams (C4) and context maps (DDD)
Present a new set of user requirements
The teams update their maps and iterate their models
The teams share their maps and models
Discussion on the benefit of user story mapping in domain discovery and modelling
Mail to participants for resources used on the day, outcome of discussions and groups exercises.
- Trond Hjorteland