Antes de empezar, definamos de manera breve y precisa el concepto de MVP (Producto Mínimo Viable).
Un MVP es la ejecución de un experimento diseñado para validar o refutar una hipótesis relevante, con el objetivo de reducir una incertidumbre y obtener aprendizaje accionable sobre el producto, los usuarios, el mercado o el problema a resolver. Este experimento no tiene por qué ser necesariamente un producto
Esta definición puede resultar sorprendente. Una búsqueda rápida en Internet muestra muchas interpretaciones que presentan MVP como un elemento integrado dentro de Scrum, incluso como un posible sustituto del Sprint Goal, de la Definition of Done o del Increment. Esta interpretación, aunque muy común, es una mala práctica que desvirtúa tanto el marco de trabajo Scrum como el propio concepto de MVP y su utilidad real dentro de un proyecto o una organización.
Cuando leemos “Producto Mínimo Viable”, tendemos a pensar automáticamente en producto, en pequeñas funcionalidades y en valor. Pero MVP no trata principalmente de eso. Trata de poner a prueba una hipótesis que no tiene por qué materializarse en un producto viable ni siquiera usable.
Es importante tener claro qué NO es un MVP. MVP y Scrum son conceptos completamente distintos, aunque pueden complementarse para facilitar la entrega iterativa de valor de calidad.
MVP no forma parte del estándar Scrum. Por lo tanto, hacer Scrum no implica en ningún caso que se esté aplicando MVP. Para empezar, MVP proviene de Lean. Scrum se ha acercado a Lean en sus versiones más recientes, especialmente en el principio de evitar el desperdicio a toda costa durante el proceso iterativo de construcción de un producto.
En 2011, Eric Ries incorpora el concepto de MVP dentro de Lean y lo define a partir de tres pilares básicos: aprendizaje, validación de hipótesis y toma de decisiones. Aquí es fundamental comprender que MVP no se focaliza explícitamente en el “producto”, sino en el aprendizaje.
Scrum tiene una fuerte orientación al incremento de valor y al producto. Y cuando aplicamos MVP, el primer impulso suele ser pensar en funcionalidades y en valor tangible. Pero MVP no es eso. MVP es una herramienta que ayuda a los equipos a mejorar su forma de trabajar para obtener mejores resultados. Para lograrlo, es necesario crear un entorno en el que el aprendizaje continuo, la prueba de hipótesis y el posible fracaso —para intentar una dirección diferente— sean posibles, aceptados e incluso promovidos.
Algunas derivadas más específicas de este enfoque, que ayudan a clarificar qué NO es un MVP, son las siguientes:
El uso del concepto de MVP no responde únicamente a la voluntad de construir más rápido o con menor coste, sino a la necesidad de tomar mejores decisiones en entornos de incertidumbre. En la construcción de un producto, el riesgo principal no es la velocidad ni el número de funcionalidades desplegadas, sino construir aquello que no aporta valor real a la organización.
En este contexto, MVP debe considerarse una herramienta de gobierno del producto. Esta herramienta permite reducir incertidumbres y orientar la evolución del producto a partir de evidencias obtenidas del mundo real —usuarios que utilizan realmente el producto—. Los objetivos dMVP pueden resumirse en uno central:
Asegurar que avanzamos en la dirección correcta en la construcción de nuestro producto
Una lista más detallada de objetivos podría ser la siguiente:
Este aprendizaje debe basarse en evidencias observables de uso y comportamiento, no únicamente en opiniones o intuiciones internas. El resultado es un incremento tangible que permite tomar decisiones informadas sobre la evolución del producto.
El uso dMVP para gobernar la creación de productos aporta una serie de ventajas clave:
Sin embargo, ignorar los tres pilares de hipótesis, experimento y aprendizaje conduce a la scrumización dMVP: convertirlo en un artefacto o ritual más dentro del ciclo Scrum. Esta confusión genera fricciones con prácticas consolidadas como el Sprint Goal o la Definition of Done, y desvirtúa tanto el propósito dMVP como el del propio marco de trabajo.
MVP no sustituye a Scrum ni se superpone a él: lo complementa. Scrum proporciona el marco para construir incrementos de calidad; MVP aporta el criterio para decidir qué incrementos merece la pena construir y con qué objetivo de aprendizaje.
Muchos equipos que trabajan con Scrum ven MVP como algo que puede incorporarse como un artefacto más en sus dinámicas habituales. En ese punto existe el riesgo de tratar MVP como una lista de elementos que aportan valor en cada Sprint. Esto, lamentablemente, simplifica el verdadero propósito dMVP, que es facilitar el aprendizaje, no entregar valor de forma cíclica.
MVP no altera el marco de trabajo Scrum. Conceptos clave como el Increment, el Sprint Goal o la Definition of Done siguen siendo piezas fundamentales. El reto consiste en entender cómo hipótesis, experimentos y aprendizaje pueden convivir sin introducir sesgos en la operativa de los equipos ni en la comunicación con los stakeholders.
Scrum tiene un foco claro y fácilmente comprensible para los equipos: proporcionar valor de forma iterativa —no necesariamente en cada Sprint, como recuerda el concepto de release— aunque sea en incrementos pequeños. Esto se traduce en artefactos y actividades orientados a seleccionar incrementos viables que permitan avanzar hacia un producto escalable, seguro y útil.
MVP se centra en el aprendizaje y en cómo este aprendizaje puede influir positivamente en la reducción de incertidumbres que guían al Product Owner en la toma de decisiones sobre la evolución del producto.
Si entendemos MVP como una herramienta para reducir incertidumbre, podemos asumir que reducir incertidumbre no siempre significa avanzar en incrementos de valor para el negocio. Hay decisiones que no pueden tomarse simplemente añadiendo más valor, sino deteniéndose y cuestionando si lo que se ha construido genera el valor correcto para seguir evolucionando el producto. Resolver incertidumbres tiene un impacto directo y positivo en definir el camino adecuado para la evolución del producto y sus funcionalidades.
MVP se relaciona con el discovery de la misma forma que Scrum se relaciona con el Sprint. Es decir, MVP busca resolver incertidumbre mediante la prueba de hipótesis para descubrir si estas son válidas o simples espejismos del mercado. Conviene aclarar que MVP no es un marco de discovery —este puede integrarse perfectamente en Scrum—, sino una herramienta enfocada al discovery y no a la producción de valor no validado.
Cuando Instagram decidió probar si mostrar públicamente el número de “likes” generaba estrés en los usuarios, no estaba pensando en aportar nuevo valor de producto, sino en resolver una duda que podía marcar su evolución futura. Es razonable pensar que, junto a funcionalidades alineadas con un Sprint Goal, se desplegó un experimento pequeño y simple para validar o refutar esa hipótesis.
Esta forma de pensar, tanto a nivel de equipo como de organización, genera un entorno en el que es posible desplegar incrementos cuyo valor es complementario a otras necesidades, y en el que existe espacio para aprender sobre el producto y el mercado con el fin de evolucionar en la mejor dirección posible.
Para concluir esta sección, el objetivo último del aprendizaje no es aprender por aprender, sino reducir la incertidumbre lo suficiente como para tomar mejores decisiones de producto. MVP no sustituye ni relaja los compromisos de Scrum, sino que convive con los incrementos orientados a valor dentro de un mismo ciclo de trabajo.
Como se ha comentado anteriormente, MVP se basa en tres pilares fundamentales: hipótesis, experimento y aprendizaje. En esta sección profundizamos en cada uno de ellos.
Una hipótesis es una suposición que inicialmente se cree cierta, pero que requiere validación, ya sea para confirmarla o refutarla. A lo largo de un proyecto pueden surgir dudas sobre si una funcionalidad o una determinada orientación del producto es realmente la adecuada.
Con MVP formulamos hipótesis diseñadas para resolver estas incertidumbres. La lista de hipótesis que van apareciendo con el tiempo debe priorizarse, ya que algunas son más críticas para el futuro del producto que otras. En función de esta priorización, decidimos cuáles se incorporan al flujo de trabajo.
El Product Owner es quien gobierna las hipótesis. Su responsabilidad es doble:
El experimento es la ejecución de una hipótesis con el objetivo de validarla o refutarla. Scrum puede actuar como vehículo de ejecución del experimento. Un experimento puede encajarse dentro de un Sprint para que el equipo lo construya y los usuarios pongan a prueba la hipótesis planteada.
Un experimento no tiene por qué limitarse a un único Sprint; puede extenderse en el tiempo. También es importante entender que un experimento puede o no generar un incremento de valor de producto. Sin embargo, el aprendizaje obtenido siempre tiene valor para el equipo y para el negocio.
El objetivo principal de un experimento es validar o refutar una hipótesis, aunque en la práctica no siempre se consigue. A menudo, las hipótesis son incompletas, los experimentos revelan nuevas incertidumbres o los resultados solo validan parcialmente la suposición inicial, lo que conduce a reformulaciones o a la generación de nuevas hipótesis.
El aprendizaje es el resultado de la ejecución del experimento: la información obtenida que permite validar o refutar la hipótesis. Este aprendizaje puede influir en lo que se muestra en la Sprint Review, modificar el Product Backlog o incluso afectar a futuros Sprint Goals.
El aprendizaje es responsabilidad de todos. El equipo aprende construyendo experimentos que pueden marcar la evolución del producto. Los stakeholders aprenden al ver confirmadas o refutadas suposiciones sobre usuarios, negocio o mercado. El Product Owner aprende al obtener una comprensión más sólida de lo que realmente es el producto en cada etapa.
Trabajar con listas de hipótesis priorizadas implica que distintas personas asuman diferentes responsabilidades en cada momento del proceso.
Esto incluye acciones de priorización, construcción de experimentos, pruebas en el mundo real y recopilación de información que permita aprender y tomar decisiones, todo ello manteniendo una convivencia sana con el marco de trabajo Scrum.
Se trata de un trabajo coral que impacta a todos los implicados en el proyecto, incluido el negocio. Una forma de abordar este reparto de responsabilidades sin caer en el error de diluir MVP dentro de Scrum es centrarse en sus pilares: hipótesis, experimento y aprendizaje.
Es lógico que la persona más interesada en resolver incertidumbres que pueden afectar negativamente al producto sea quien lo gobierna. Por ello, el Product Owner es el principal responsable de recopilar y priorizar las hipótesis.
Esto no significa que el Product Owner actúe en solitario. No puede “inventar” hipótesis. Los stakeholders aportan información clave sobre contexto, restricciones, objetivos de negocio y condicionantes legales, políticos o de mercado que generan incertidumbre.
El Product Owner incorpora activamente —no delega— este contexto en la definición de la lista de hipótesis. La responsabilidad final de la priorización sigue siendo suya y se basa en criterios de riesgo e incertidumbre, no en esfuerzo o complejidad técnica.
Una vez que el Product Owner decide que una hipótesis debe someterse a validación, corresponde al Scrum Team incorporar las tareas técnicas necesarias dentro de uno o varios Sprints para construir el experimento.
El Scrum Team es responsable de diseñar y construir el experimento de la forma técnicamente más adecuada, pero no de decidir qué hipótesis es prioritaria ni cómo deben interpretarse los resultados.
Una vez desplegado el experimento, el foco vuelve a los stakeholders o, más concretamente, a los usuarios o al mercado que harán un uso real del mismo. El equipo técnico sigue involucrado proporcionando soporte, ajustes o soluciones técnicas cuando es necesario.
El resultado es información en forma de métricas, KPIs —indicadores clave—, estadísticas y otros datos relevantes que permiten validar o refutar la hipótesis inicial.
Finalmente, una vez validada o refutada la hipótesis, el Product Owner dispone de información de valor para interpretar el aprendizaje y tomar decisiones sobre el futuro del producto: perseverar en la dirección actual, reorientarla o seguir investigando si la incertidumbre no se ha resuelto por completo.
Estas decisiones suelen tener impacto sobre artefactos de Scrum como el Sprint Goal, el Product Backlog y los Increments. La validación o refutación de una hipótesis puede modificar la priorización y el contenido del Product Backlog, así como los objetivos de futuros Sprints.
Para cerrar este artículo, es fundamental insistir en una idea clave: MVP no es una técnica que forme parte del marco de trabajo Scrum, ni una actividad o artefacto que pueda añadirse sin más. Entender MVP de este modo es una mala práctica que desvirtúa tanto su propósito como el del propio Scrum.
MVP es una estrategia orientada a reducir incertidumbres críticas que pueden condicionar gravemente la evolución de un producto. Su foco no es incrementar funcionalidades, sino aportar una visión del valor basada en la reducción de riesgos mediante evidencias reales.
A través de hipótesis explícitas, experimentos diseñados para ponerlas a prueba y el aprendizaje que se deriva de ellos, MVP obliga a equipos y organizaciones a enfrentarse a una realidad a menudo incómoda: decidir. Cuando se utiliza con rigor, MVP no sustituye a Scrum ni relaja sus compromisos, sino que complementa el gobierno del producto. Pero solo funciona cuando existe una voluntad real de aprender y de actuar en consecuencia.
![calaix[À]gil.com](/img/logo.png){kind=logo}
