Quickly gain value with Minimal Marketable User Flow

Visible value, user stories, epics, and user flow

Value needs to be easily visible: that’s a fact. It should be part of every user story, as the format of a user story dictates that As Someone, I want to do Something because it creates a certain Value. Value underlies the motivation for a user to act.

Still, what is the value behind a button that furthers someone’s journey in a process? Not to end a process, but just to continue to the next step of the process? It is hard to define, since that step in the user flow doesn’t have any value in and of itself, without the steps that follow which lead to concluding the process.

At the same time, a user story that encapsules an entire user flow (the journey a user makes through a service while using that service) is too large and would need to be broken up into an enormous number of tasks so that it becomes clear to everyone working on the story. 

Besides user stories, we often work with epics. Epics are usually centered around a theme like payment, registration, or a webshop’s inventory. They are always broken up into user stories before development takes off. Building an entire epic before releasing it is often not cost-effective. In any case, to actually add value with an epic we often need functionality that is part of other epics. For instance, in order to sell something to a customer they need to be registered, they need to use the shop’s inventory, add items to a basket, and use the payment process.

This sequence of events is called a user flow. Let’s say one user completing a flow from start to finish. Most services have several user flows and all user flows should eventually add value, since there would be no reason for a user to complete the flow without wanting whatever it is that happens to be the goal of the user flow. One thing also indigenous to user flows is that it takes into account how the user feels while in that user flow. This is done using personas. That might seem less important, but it actually has great impact on the value of the user flow and therefore the user stories that are created as a result.

User flows have been around for a long time. So has scrum. As is often the case, the best things happen when multiple worlds meet and create one continuous process. That is what I aim to describe below, as well as some practical tips on how to make tooling work for you in this regard.

Minimal Marketable User Flow: the process

The process starts with a workshop in which you will create the desired user flows. The end result should be a wireframe of the user flows. It could well be a Design Sprint which has room to create the user stories based on the user flows. If at all possible, at the end of these workshops you will also want to have a clickable prototype!

Why are clickable wireframes/ prototypes important?

Well, the answer is rather straightforward. We don’t want to invest our time and resources in a project if we know it will fail.

With a clickable prototype, it is easy to perform User/Usability Testing: testing the prototype with actual users in a research environment (if possible, a controlled environment where all reactions and interactions can be recorded.) Usability testing gives you your first data on usability and the likelihood that your service is adopted by users in the future. This is the earliest moment you can get user feedback. Early changes are much cheaper than changes made later on in the process. Now you are one step closer to ensuring you can actually get the proclaimed value out of your work!

These user-tested wireframes, including their changes based on the results of user testing, are the input for your projects backlog. Usually, you create theme-based epics and you try to find the minimal functionality required for your first release. In other words, you’re describing your Minimum Viable Product. While determining these minimum requirements, you build them around the user flows that are the result from your first workshops and user testing. Let’s take the case of your main customer base paying by credit card.

You don’t need to build the entire payment epic but just the parts needed for the user flow where the user pays using a credit card.

At Eficode we call this user flow the Minimal Marketable User Flow (MMUF). Several of these combined will likely form your Minimum Viable Product (MVP) as shown in the picture above.

After releasing your MVP, you will add Minimal Marketable Features (MMF) as they become available. Some MMFs include only one MMUF and others multiple.

Get User Stories quicker: Design Sprints

There are several ways of getting user stories directly out of design sprints. If you know what happens during a design sprint, however, you can imagine there is no time during the sessions to make these user stories based on the user flow. It would slow down the workshops thereby making them less effective. However, you could either have some days in between, or a couple of hours at the end of the day or at the end of the design sprint, to do this documentation work. This can work as long as you don’t interrupt the flow of the workshops themselves.

By taking this approach, you will be ready to start production right after the design sprint. Not only do you have a good set of high value epics, user flows, and user stories: you also have a solid understanding of the needed architecture.

Tools to save you time

Tools are tools: nothing more or nothing less. They are nothing if they are not used right. At the moment, for registering and tracking requirements, I use Jira by Atlassian. I’ve found that this tool can perform the tasks needed for this process.

User stories, Epics and Tasks are the basic elements of most Jira boards. Tasks usually belong to User Stories and User Stories to Epics. However, User Flows are not really part of this tooling.

Using Labels allows you to label all stories as part of a predefined User Flow: allowing you to group them as shown in the diagram above. A second option that allows you an easy way to filter them is to use Components. User stories and Tasks can belong to a component giving you an easy way to filter them.

By using integrated tools like using Eficode’s Root, you should be able to track your user flows in your code. This will allow you to identify frequently-used parts of your code (as well as the parts of the code you will touch when changing an existing user flow) by using Smart Commits.

In order to do this, you need to commit every user story and task connected to that user flow. With simple commands, it is possible to find the code that was committed during a specific commit. For instance, the command “git log -S searchTerm” will get you any commit with that search term. Smart Commits can also be used to auto-create and release fixed versions in Jira.

Who should be involved in setting up this user flow process?

This kind of process doesn’t work just like that. You need to ensure all disciplines are involved and well aware of each other’s capabilities.

• Service Designers help the customer to create the initial concepts and user flows.
• UI Designers  create low fidelity clickable prototypes that are tested during the first stages by the end users of the service.
• Developers and Architects  are part of the process in order to stay ahead of the curve on technical issues that might arise during the project, like integrations and migrations.
• User testing experts ensure that user tests are done in such a way that they result in useful feedback.

All these disciplines need to work seamlessly together. This is the core reason why at Eficode we have put all these disciplines in one department instead of having siloed development, design, and research departments. You can take this one step further by creating tightly-knit teams of people coming from all of these disciplines (at least that’s what we’ve done!). People that know each other because they communicate on a daily basis end up syncing up over time to play like a band instead of a mishmash of star performers and all the ensuing drama.

Mervi Rauhala, Eficode’s Project Manager for Digital Transformation & Service Design, contributed to this blog. She gives training sessions on a range of topics including service design. She’s also co-authored a Finnish-language book about storytelling in the business environment: "Storytelling työkaluna - vaikuta tarinoilla bisneksessä”.