Minimum Valuable Increment

Overview

The Minimum Valuable Increment allows you to deliver your Strategic Area in small parts. This provides the following benefits:

  • Able to stop quickly if results aren’t as expected

  • Time to market reduced

  • Value gained from the work is sped up

This does not mean releasing features with very little functionality and testing them. It means figuring out the balance between sufficient functionality to solve a problem and nice to-haves.

Problem statement

  • Using the problem statement format

    • The problem of [description]

    • Affects [persona]

    • The impact is [ideally quantified]

  • The problem that this solves. This will be linked to the Strategic Area’s problem statement but at a more granular level. You should still consider research to quantify the statement. The research effort to produce this should be balanced against the size of the change.

Objectives and Key Results

  • The Strategic Area also has OKRs, however the key results may take a long time to come back. Therefore OKRs are also created for the MVI, providing faster feedback.

  • Using the OKR format

    • Objective - a single sentence

    • Key Result - From [X] to [Y] by [Z] date

  • The objective should be an easy-to-understand sentence

  • Key Results can be “committed” where outcomes are guaranteed or “stretched” if they cannot be

User Experience (UX) concept

  • If you are working with any sort of visual interface the UX concept can help bring understanding and alignment. Visualisations can be much easier to understand than text based descriptions. It can be used to validate business and technology solutions and form the basis of user testing. The concept does not need to be high resolution, especially if this means its creation will be slow and make it difficult to change.

Solution definition

  • There may be multiple options. Consider the impact of tactical solutions.

Identify assumptions

  • Feasibility - can it be built?

  • Desirability - do customers want this?

  • Viability - does the business case stack up?

MVI Build Process

MVI Build Process

Test assumptions

Assumptions are prioritised, and tests are run to remove them. For example, you may not be sure if a new server architecture will be performant (feasibility). After assumptions testing, you may decide to stop the build or even question the entire strategy. Some assumptions may be carried into the build stage when:

  1. They are too difficult to test quickly

  2. They are not important enough to test early

Estimate

We can now estimate having removed the significant assumptions, particularly those relating to feasibility (can we build it?).

Build

Progress is tracked here. The product burnup is a useful artefact for understanding the speed at which the team is delivering and the level at which scope is increasing. Delivery risks and issues should also be carefully managed.

We may also run additional testing such as:

  • Alpha testing - internal user testing to check quality and overall functionality

  • Beta testing - testing with a subset of real users

Assess

The success of the MVI can be judged against its OKR. If results are available, the overall OKR in the Strategic Area can also be reviewed. If results are poor, we may decide to pivot or simply stop.