Trying to be an agile superman...

but still hanging on to big bang releases?


December 2018


Christian Mark Christensen

A systematic approach to identifying MVPs

Despite the ambition of working with agile methodologies, leveraging the concept of minimal viable products (MVPs) to release small chunks of functionality on a continuous basis during the project, many companies developing large and complex solutions end up using a de-facto waterfall approach.

That means that they do not minimise their overall risk by releasing the solution continuously, and it also means that they do not get one of the central effects in agile – to maximise the amount of work they don't do. Or in other words, they produce more than necessary to reap the forecasted benefits of the project. The overall effect is that they do not get the financial upsides from the substantial investment there are in having an agile transformation.

Figure 1. Storyboard from a client-faced web application.

The big questions are what we can do to identify an actual MVP when we look at large complexity in any solution? And what we can do to facilitate a discussion among everyone involved in the future solution in order to create a shared perception of what the solution consists of?

The answer to both questions is to grab into our agile toolbox and invest some time in the refinement process of making a story map. Once you have done that, it is hard to live without it.

Identifying the MVP and making your project truly agile

The reason for pursuing an MVP is that we want feedback on the solutions we make. Sometimes, we want technical proof that an idea is viable and can be done, and sometimes we want feedback from our clients. The client feedback is often referred to as a minimum marketable product. No matter if we pursue technical and/or client feedback, the main point is that we want feedback that we can trust and that we can build on, before we continue developing in a specific direction.

Figure 2. Example of a storyboard with backbone, walking skeleton and meat.

The storyboard is a perfect way to facilitate a discussion on just how little we need to develop in order to have a minimum feature set that will give us valuable feedback.

What is a story map?

Basically, story mapping is a way to break down large epics/projects into a visible overview of your solution. It consists of three parts; backbone, walking skeleton and meat to the skeleton.

Figure 3. Story map with both web and native application.

Walking skeleton – When making your story map, you start with a description of what kind of main steps you have in your solution. First step, “main page”, second step, “article page” and so on.

Backbone – or hooks to our walking skeleton – is the level over the walking skeleton. It is a useful method to easily get an overview of the entire solution. We do not start with the backbone, because it is easier to consolidate the steps in the walking skeleton. Simple backbone examples can be “awareness”, “sales flow” and “aftersales”.

Meat – or what will be your future user stories. In every “main step” in your walking skeleton, you break down the specific step in user stories. If you have not worked with user stories before, they are a formalised way to facilitate a dialogue around smaller parts of the story map. First, they are only headlines, but during the refinement process that consists of discussions with stakeholders and experts, you will soon get the first part of your product backlog refined up to “definition of ready”.

An important point is that the main difference between a waterfall approach and agile is that it is –roughly speaking – the direction of your slicing that determines your approach, and whether you reduce your overall risk continuously or only at the end of the project life. Horizontal slicing includes more steps with fewer user stories at every step in the walking skeleton. Vertical slicing means only one step in your walking skeleton, including all user stories.

A way to foster collective intelligence and conversation

The best story maps are those that have a good mix of cross-functional competencies embedded in them. When you facilitate your storyboard workshops, be aware how you involve and unfold the intellectual capacity from all attendees and not only the ones that normally talk the most. It can create value to invite other experts inside (or outside) your company to contribute to making your storyboard a creative and very visual way to present your future solutions. The point is that you should try to create your story map in collaboration with people you know think different than yourself.

Figure 4. Storyboard from an internal system supporting labour agreements in a large financial institution.

The discussions around the story map will be more energized – and maybe even frustrating sometimes. This will, however, be outweighed by the sheer happiness and satisfaction of having achieved something amazing together with people that think different. Creating something that is truly better than what you would have been able to create alone is fantastic.