MVP (Minimum Viable Product) is a product with the minimum set of features that can be delivered to users for actual use. It is used to validate ideas during software development while minimizing resource expenditure. Typically, an MVP is achieved through effective release planning, where the first release contains only the core functionality (or even a single most important feature). This allows users to start using the product without waiting for the final version and provides an opportunity to collect feedback that can guide future product development (according to Wikipedia).
The task of defining MVP functionality arises during the product development planning phase and often requires continuous refinement as the product evolves, up until the completion of MVP development.
The MVP concept is based on delivering a product to end users as quickly as possible in order to obtain feedback. However, product owners often go beyond the minimum required functionality in an effort to improve the product, which can result in missed deadlines, budget overruns, and, in the worst-case scenario, product development moving in the wrong direction.
To minimize these risks, a specific approach based on mathematical principles is proposed to support and regulate the process of defining MVP functionality.
The criteria used for MVP functionality definition are derived from the WSJF methodology, supplemented by a decomposition of Job Duration into additional components.
User-Business Value — How much are users expecting this feature? What is the financial impact if it is NOT implemented? What potential negative consequences may arise if it is delivered later rather than sooner?
Time Criticality — How does this affect the overall delivery flow? Does it delay other initiatives? Does it need to be released by a specific date? Is there a risk that a delay will significantly reduce or eliminate the value of the work completed?
Risk Reduction — Does this feature reduce any risks? Will it positively affect quality in other areas? Will its impact be immediate or long-term?
Opportunity Enablement — Will this feature create new opportunities for the product or the business as a whole? Will it help enter new markets or attract new customers?
Job Duration — An estimate of implementation time based on a preliminary feature analysis performed with the participation of a Technical Lead, Team Lead, or Solution Architect. This estimate is performed at a high level without breaking features down into lower-level tasks.
Job Complexity — An estimate of implementation complexity performed jointly with the development team's Team Lead, taking into account the skills and experience of the team working on the product. This assessment also includes the level of uncertainty associated with a feature, which directly affects its complexity.
Job Cost — An estimate of implementation cost calculated by multiplying the required number of person-hours by the cost per person-hour within the team. This estimate is relative and should not be used for product pricing purposes; it is intended solely for backlog prioritization.
Assessment is performed using the Fibonacci sequence values from 1 to 21 (1, 3, 5, 8, 13, 21). This estimation method is universal and can also be used for Story Point estimation during planning sessions. Scrum Poker can additionally be used for collaborative scoring of the criteria.
The Fibonacci scale is used because the difference between values increases non-linearly, making it harder to oversimplify evaluations into a single score. It also makes distinctions more visible—for example, the difference in business value between an item rated 3 and one rated 21 Story Points becomes immediately apparent.
Assessments for the Job Duration criteria group are performed by the development team, while assessments for the Cost of Delay criteria group are performed exclusively with the participation of the business stakeholder and the Product Owner.
The resulting evaluation matrix has the following structure:
| Feature Name | User-Business Value | Time Criticality | Risk Reduction | Opportunity Enablement | Job Duration | Job Complexity | Job Cost |
|---|---|---|---|---|---|---|---|
| Feature1 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 |
| Feature2 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 |
| Feature3 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 |
| FeatureN | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 | 1–21 |
Multi-objective optimization is the process of simultaneously optimizing two or more conflicting objective functions within a defined domain. One of the simplest approaches to solving a multi-objective optimization problem is the criteria aggregation method, which converts a multi-objective problem into a single-objective one.
The criteria aggregation method transforms a set of individual criteria into a single super-criterion, which is expressed as a function of the original criteria.
To aggregate the criteria, weighting coefficients must be introduced.
| Coefficient | K11 | K12 | K13 | K14 | K21 | K22 | K23 |
|---|
Separate weighting coefficients should be established for business-related criteria and development-related criteria.
The aggregated criteria are calculated as follows:
Cost of Delay = (User-Business Value × K11) + (Time Criticality × K12) + (Risk Reduction × K13) + (Opportunity Enablement × K14)
Jobs Duration = (Job Duration × K21) + (Job Complexity × K22) + (Job Cost × K23)
Constraints:
Overall Optimization Criterion (Mutual Criteria):
Mutual Criteria = Cost of Delay / Jobs Duration
The resulting matrix takes the following form:
| Feature Name | Mutual Criteria |
|---|---|
| Feature1 | MC1 |
| Feature2 | MC2 |
| Feature3 | MC3 |
| FeatureN | MCN |
The objective function is the maximization of the Mutual Criteria value.
ABC analysis is a method used to classify tasks according to their importance. It is a rationalization technique that can be applied in virtually any business area. It is based on the Pareto Principle, which states that 20% of effort generates 80% of results.
In the context of MVP planning, the Pareto Principle can be interpreted as follows:
20% of the functionality satisfies 80% of user needs.
ABC analysis divides the backlog (a set of features) into three categories:
Category A represents the functionality that constitutes the MVP.
Essentially, ABC analysis is a method of ranking backlog items according to their relative impact. The result is a grouping of features based on their contribution to the overall outcome.
ABC analysis is based on the principle of imbalance and uses a cumulative distribution graph known as the Pareto Curve, Lorenz Curve, or ABC Curve. According to this principle, 20% of functionality covers 80% of user needs. This concept is applied to backlog analysis for MVP determination.
The process is as follows:
Core functionality must always be considered.
Category A may coincide with the Core functionality, but if it does not, the results of the ABC analysis must be supplemented with the Core features.
Core functionality represents the foundation of the product and includes the features without which the product cannot operate. Examples include authentication and authorization capabilities.
Applying this methodology to define the feature set for an MVP provides a structured and justified approach for selecting the optimal number of features required to deliver the MVP as quickly as possible. By combining WSJF-based evaluation, multi-objective optimization, and ABC analysis, organizations can reduce the risk of scope expansion, prioritize functionality objectively, and focus development efforts on the features that provide the greatest value relative to implementation effort.