Article

Trying to be an agile superman...

but still hanging on to big bang releases?
Published

7 December 2018

A systematic approach to identifying MVPs

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

This means that they do not minimise their overall risk by releasing the solution continuously, and it also means that they do not achieve one of the key effects of agile, i.e. to maximise the amount of work they do not do. 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 upside from the substantial investment of carrying out an agile transformation.

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

So, the big question is what can we do to identify an actual MVP when we look at large complexity in any solution? And what can we 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 come up with. Sometimes, we want technical proof that an idea is viable and can be carried out, and sometimes, we want feedback from our clients. 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 added 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 above 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 of the walking skeleton. Simple backbone examples are “awareness”, “sales flow” and “after-sales”.

Meat – or what will be your future user stories. In every “main step” of your walking skeleton, you break down the specific step into user stories. If you have not worked with user stories before, they are a formalised way to facilitate a dialogue about smaller parts of the story map. At 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 –roughly speaking – it is 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 of the walking skeleton. Vertical slicing means only one step of 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 of how you involve and unfold the intellectual capacity of all attendees and not just the ones who normally talk the most. Inviting other experts in (or outside) your company can create value by them contributing 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 differently than yourself.

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

Discussions about the story map will be more energised – and maybe even frustrating at times. However, this will be outweighed by the sheer happiness and satisfaction of having achieved something amazing together with people who think differently. Creating something that is truly better than what you would have been able to create on your own is fantastic.

Related0 4