Defining the Minimum Viable Product
When Eric Ries helped popularise the concept of the Minimum Viable Product (MVP) in his book ‘The Lean Startup’,
he defined it as ‘that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort’ . This supports products with a clear external customer and an anticipated revenue stream; allowing the team to focus on specific user sought enhancements and features while minimising the risk of wasted time and effort developing features that are not wanted. On the other hand, what if the product is being developed for internal company use; where the functionality required is fully scoped and defined? Is developing an MVP still a worthwhile activity?
In this case there are a number of benefits that can be realised by defining a Minimum Viable Product; for example, and most importantly, it enables the Product Owner to:
- better optimise the Product Backlog and
- descope user stories with more precision when required.
So why is defining the MVP rarely done for internal projects? There are a number of reasons for this and it can vary from project to project. I have been involved in a number of projects where the MVP has not been used. There have been a variety of reasons why this is the case:
- The project is not truly agile; the Product Owner working on behalf of the client has defined user story as a ‘Must’.
- Difficulty getting client buy-in; while they may support user story/requirements prioritisation, they refuse to relinquish features which are essentially enhancements to an MVP.
- The product backlog is never truly completed; if the MVP is constantly evolving it is felt that it is not worth the effort developing in the first place.
However, this does not have to be the case; defining the MVP for a product should not be a burdensome task. To help us develop the MVP for internal products, or any product whose required functionality is fully known, we must first understand the purpose of the MVP and define it.
The purpose of the MVP is to deliver a working product, fulfilling the goal of the project. It does not preclude the delivery of features that add to, or enhance the MVP but allows the team to focus on the core functionality when user stories need to be descoped or new user stories are added to the backlog following testing and sprint reviews. It is important to remember that delivering an MVP allows for user feedback that that can greatly enhance the final delivered product. The MVP is not the delivery of a product with minimal functionality.
Marek Hasa identified the key elements of an MVP as follows:
- Functionality – a bundle of features which are all intertwined and can be used to reach a goal within the product and receive specific value
- Design – needs to meet the commercial quality standards so that the feedback of your target users is not biased by amateurish execution
- Reliability – needs to be thoroughly tested and fully functional
- Usability – users are able to complete target actions and gain specific benefits from using the product
The issue is identifying what the core functionality is.
So, what is the best way to identify the core functionality and define the MVP? Traditionally, this has been done through prioritisation of user stories in the product backlog or using a user journey map. Neither approach, because of their discrete nature, allows the analyst/product owner to fully understand how the user stories deliver the project goal. These approaches can also miss system features from the MVP.
To identify the core functionality of a product it is necessary to understand the relationship between the features being delivered. This relationship is frequently more than just a user journey map and needs to capture the actions required to deliver the project goal, the data requirements and non-functional requirements. The latter two support the implementation of the design and reliability needs of the MVP. Modelling this relationship allows the Business Analyst to ascertain the core functionality, the key end to end flows (though ideally this is only a single flow) that deliver the project goal. By mapping user stories to this flow a Business Analyst is able to easily identify the functionality/user stories that are not directly relevant to these flows. They can also identify functionality that can be simplified or delivered via a workaround and enhanced in a later iteration. Examples of functionality that may not be considered part of the MVP include:
- Automatic upload of data via an FTP site – an interim solution may be users uploading data from an email attachment
- Calculations that handle exceptions to the norm – an interim solution may support the calculations being done outside the product and the results entered manually
Once the MVP has been identified user stories can be prioritised accordingly. The description of this relationship should not be detailed; it is a high-level understanding enables analysis of what is required to deliver the project goal. The detail will be expanded upon as part of the user story refinement ahead of inclusion in a sprint. This approach enables the user stories to be easily added and removed from the definition of the MVP and the impact of those changes to be assessed.
We have looked at the role of the MVP in an agile project and how it can be utilised in projects delivering software for internal use. We have also shown how an MVP can be identified in such an environment.
Should an MVP be the cornerstone of any agile project? To better deliver a product using agile it needs to be. The benefits of identifying an MVP are:
- better user story prioritisation;
- user story descoping without losing core functionality and;
- allows user feedback on the product so specific user sought enhancements and features can be delivered