Are you in a company that is customer obsessed, striving to create solutions that focus on 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 modelling in this highly 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. Story mapping is not only a tool for product discovery, but also domain modelling and product delivery, being a tool to cross the chasm between business and IT, i.e. the problem and solution domain.
We will create a map for a concrete product taken from the pay TV domain, trying to follow all the phases of the product discovery and learn 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.