“Tres Anillos para los Reyes Elfos bajo el cielo. […] ”

No, perdón, esto no iba aquí.

“Una “eme” para el mínimo producto viable de nuestro producto.
Otra para el mínimo producto comercializable entre nuestros usuarios.
Otra “eme” para una mínima versión comercializable que amplíe la funcionalidad.
Una para la funcionalidad que aporta valor.
En la definición del backlog de producto donde se extienden las Sombras.

Las “emes” para gobernarlas a todas, para encontrarlas,
para agruparlas a todas y atarlas al producto
en el backlog de producto donde se extienden las épicas y las historias de usuario.”

Índice

• Introducción
• Conclusiones
• El método
• Paso 1: Identificar las fuentes
• Paso 2: Analizar cada concepto y hacerse una composición de lugar
• Paso 3: Ampliar la visión más allá de los conceptos explícitos
• Paso 4: Elementos adicionales y aplicación de la experiencia

Introducción

Hace poco entre los coaches de Autentia surgió una discusión en cuanto a las agrupaciones funcionales de un producto, concretamente el MVP (minimum viable product) y las MMF (minimum marketable feature) ya que había diferentes aproximaciones y era algo que se repetía en nuestros clientes.

Tengo que agradecer a mis compañeros Jeselys y Javi, que cada uno me aportara una visión diferente, ya que me hizo plantearme analizar con más detalle -del que originalmente consideraba- el solapamiento entre conceptos y que finalmente ha dado como fruto esta entrada. ¡Gracias chicos!

En nuestro día a día es fácil hablar de Épicas, Historias y Releases, pero cuando nuestros productos adquieren dimensiones épicas (y por eso la intro tipo El Señor de los Anillos), podemos apoyarnos en los siguientes elementos adicionales que nos ayuden a agrupar y gestionar la funcionalidad:

• MVP – Minimum Viable Product
• MMF  –  Minimum Marketable Feature
• MMP  –  Minimum Marketable Product
• MMR  –  Minimum Marketable Release

OJO!!! No siempre son necesarios y debemos tener cuidado de no introducirlos si no tienen sentido porque lo único que harán será añadir complejidad.

Con estos elementos lo que ocurre, como en tantas otras ocasiones, es que los términos se han usado de forma inconsistente a lo largo de tiempo, a lo que hay que sumar que su significado varía dependiendo del dominio de utilización. Es decir, no significa lo mismo hablar de MVP con una persona de negocio (que busca confirmar su idea con un público real para seguir invirtiendo), que con un ingeniero (que busca resolver una incertidumbre técnica que haga viable un desarrollo).

En las primeras búsquedas rápidas que hice sobre los términos a partir de nuestra discusión interna no conseguí llegar a una conclusión clara, buceé entre blogs, glosarios, infografías…, entradas puntuales que no me daban “garantías”. Llegaba al mismo punto que durante nuestra conversación en Autentia. Esto me llevó a plantearme dedicar algo más de esfuerzo y establecer un método para llegar a una solución y homogeneizar los criterios que usábamos al respecto como equipo.

 

Conclusiones

Como muchos querréis ir, como dirían los Chilenos «al tiro», lo primero que os dejo es el escenario final al que nosotros hemos llegado; vamos el resumen ejecutivo con las definiciones que utilizamos. ;).

Si tienes un interés por profundizar y comprender mejor los resultados, te invito a leer más allá de las conclusiones del post y ver cómo hemos llegado hasta aquí con algún ejemplo visual.

• MVP – Minimum Viable Product, debe estar enfocado a realizar una «prueba de concepto» o experimento, y mediante ésta validar una hipótesis o adquirir un conocimiento (usuario, negocio o técnico).
• MMF  –  Minimum Marketable Feature, son las características mínimas con las que debe contar una funcionalidad para poder ser entregada a los usuarios finales.
• MMP (o MMR1)  –  Minimum Marketable Product, es la agrupación de varias funcionalidades o MMFs que entregamos en la primera release. Es lo que comúnmente se confunde con MVP.
• MMRx  –  Minimum Marketable Release, releases posteriores al MMP o MMR1 que contienen funcionalidad. Pueden contener o no MMFs.

Como podemos ver, se trata por tanto de conceptos muy próximos y que pueden llevar a confusión, por ello creo que es una buena práctica el intentar aproximarse a través de otros elementos como son las Épicas, Historias, Spikes y Chores.

 

Como resumen y siguiendo la imagen anterior, podríamos decir que una MMF es la parte de una épica que aporta mayor valor y que puede ser considerada con funcionalidad mínima.

Una MMF debe entregarse de forma íntegra en una misma versión, mientras que una épica puede desarrollarse a lo largo de varias versiones hasta completar toda su funcionalidad.

Una MMF puede estar constituida por una o más historias de usuario (u otro tipo de item).

Una Historia de usuario podría ser una MMF, pero considerando siempre que MMF tienen que ser entregable al usuario, si hablamos de una única historia y esta no aporta  por sí misma suficiente al usuario como para entregarla de forma independiente, no podremos decir que es una MMF.

NOTA: Recordad el punto más importante, no introduzcamos elementos complejos que no sean  necesarios a nuestros equipos o en nuestras organizaciones. Recordad el principio de simplicidad.

 

El método

Ahora sí, si estás aquí es que te interesa profundizar más en cómo hemos llegado a esta definición que nos ayuda en nuestro día a día. Sin volvernos locos, el método de trabajo que se ha seguido ha sido:

1. Realizar búsquedas rápidas para intentar identificar las acepciones más utilizadas.
2. Identificar las fuentes reconocidas de definiciones explícitas de los términos y el contexto en el que se producían (hablamos de MVP y MMF).
3. Analizar y comparar mis conclusiones con las que había identificado en las búsquedas rápidas.
4. Contrastar con nuestra experiencia y nuestro modelo de trabajo habitual.
5. Poner en común con el equipo y llegar a un acuerdo.
6. Compartir las conclusiones.

 

Paso 1: Identificar las fuentes

A partir de las búsquedas rápidas que mencionaba antes, establecí una red de referencias que llevaba a las mismas fuentes (esto lo cito para que cualquiera pueda reproducirlo y no sea una mero comentario como aquellos por los que he tenido que navegar yo). Podemos decir que se reducían a tres, dos sobre el MVP y una sobre la MMF:

1. MVP ha sido acuñado en el libro Lean Startup por Eric Ries, y por otro lado Jeff Gothelf y Josh Seiden también hacen uso de él en el libro Lean UX.
2. MMF ha sido establecida por Mark Denne y Jane Cleland-Huang en el libro Software by Numbers.

Hay bastantes referencias también al método IFM, The incremental funding method: data-driven software development (Jane Cleland-Huang), donde se asocia el «value» con los aspectos económicos de un producto como el ROI o el NPV. Para no complicarlo más, por el momento vamos a dejar expresamente este aspecto un poco al margen.

 

Paso 2: Analizar cada concepto y hacerse una composición de lugar

Una vez obtenidas estas referencias de las fuentes, me he ido a ellas para consultar las definiciones:

Lean UX – PMV y experimentos (Capítulo 5) o Minimum Viable Products and Prototypes (hay modificaciones en la segunda edición del libro). Literalmente (os recomiendo hacer la lectura original para extender un poco la idea de MVP y los tipos que existen) me quedo con:

» […] When it comes to creating an MVP, the first question is always what is the most important thing we need to learn next? In most cases, the answer to that will either be a question of value or a question of implementation. […] «

Sintetizando, el MVP puede tomar dos vertientes:

• – PoC: Prueba de concepto, es un esfuerzo del equipo en probar unas hipótesis o adquirir unos conocimientos necesarios antes de avanzar en el producto (rápido y “barato”). Puede ser algo tan sencillo como crear una página web «tonta» que presenta información del producto para ver métricas de leads que tengan potencialmente interés. No necesariamente tiene que haber funcionalidad construida.
• – PMV: Producto mínimo viable, que es cuando se libera un mínimo de funcionalidad construida (una unidad “comercializable” sea de pago o no). Puede ser una versión muy reducida que busca explorar sobre qué características tenemos que trabajar porque son las que más aceptación tienen entre nuestros clientes.

Software by Numbers – Software Development after dot.com (Capítulo 1)

Definición literal de MMF:

» […] We’ve spoken earlier about the idea of software development as a value creation activity. In this section we give components of value the ability to be referenced and posit the existence of minimum marketable features (MMFs). MMFs are units of software value creation. They represent components of intrinsic marketable value.

[…] What is particularly unique about software products is that the features are often, or even usually, separately deliverable. In other words, a complex software application can have value to a user even if it is incomplete. Indeed, it is often claimed that software is by its very nature always incomplete!

By carefully choosing the way in which software components are assembled, we can create identified units of marketable value well before the application is anywhere near completion. […] «

Paso 3: Ampliar la visión más allá de los conceptos explícitos

Además de los párrafos anteriores, he revisado el resto de menciones y los capítulos completos de los libros, en ningún sitio limita el uso del MVP, pudiéndose usar un MVP asociado a una funcionalidad o a un grupo de ellas, si pensamos sólo en una es donde comienza el solape con el MMF, ya que podríamos considerar estar hablando de lo mismo.

Es importante aclarar en este punto que también podría solaparse con el concepto de historia de usuario.  Una MMF debe tener un volumen de funcionalidad necesario como para ser un entregable al usuario, mientras que, una historia de usuario no necesariamente.

Volviendo a revisar la definiciones que comentaba al inicio (MMP y MMR), podemos llegar a la conclusión que puede existir solape entre la primera MMR (que puede recibir la denominación de MMP) y un MVP; una primera MMR puede ser únicamente el MVP.

Es decir, virtualmente podríamos no encontrar diferencia entre MVP, MMP, MMR y MMF si sólo afectase a una feature que fuese auto contenida, es decir, que podemos entregar como una primera funcionalidad (desarrollada o fake) al usuario final para conseguir un aprendizaje.

¡Vaya jaleo!, parece que todo sirve para todo…

 

Paso 4: Elementos adicionales y aplicación de la experiencia

Pero… ¿entonces cómo salimos de este lío de nombres y agrupaciones? ¿Cómo podemos enfocarlo de una forma simplificada que se pueda contar fácilmente?.

Para ayudar a deshacer este entuerto, hemos metido más elementos en la ecuación, las historias Épicas y las historias de usuario. Al contrario de lo que podría pensarse, introducir estos elementos nos ayuda a establecer un gobierno.

Para ayudar a digerir el texto, vamos a secuenciar los conceptos con un gráfico que nos ayude “cronológicamente” (entre comillas por que no es del todo exacto, es una referencia dado que la casuística puede ser infinita). Vamos a considerar la cajas verticales, versiones o entregables y los MMF como bloques de funcionalidad que pueden ir asociados a ellas.

 

Vale, si hemos dicho que una MMF es un bloque de funcionalidad, ¿cómo las encajamos como Épicas e Historias de usuario?

Vale, en primer lugar volvemos a nuestra jerarquía básica: Épicas, Historias y Subtareas. Vamos a establecer que una épica es aquella historia demasiado grande como para realizarla en una iteración de trabajo, es decir, es necesario descomponerla en Historias de usuario (HdU) que sí podamos acometer.

Cuando hacemos esto es muy normal que pasen dos cosas al descomponer la historia épica (puedes ver técnicas de descomposición aquí):

1. Que algunos elementos sean “poyaques” es decir no sean estrictamente necesarios como funcionalidad mínima indispensable.
2. Que algunas historias sean funcionalidades auto contenidas que no requieran de otras para aportar valor real al usuario final.

Vamos con un ejemplo, tenemos la Épica1 que se descompone en 7 Historias de usuario:

 

Pero de estas 7 historias:

• 3 suponen la funcionalidad mínima indispensable que podemos entregar al usuario final (o comercializar). Por lo tanto podemos agruparlas como la MMF de la Épica 1.
• 2 son historias que habíamos introducido con el concepto “pues ya que estamos” («poyaque») y que al analizarlas realmente no forman parte de la MMF.
• 2 son historias auto contenidas y que no pertenecen realmente a la Épica 1.

Si representamos visualmente nuestra funcionalidad quedaría organizada más o menos así:

Ahora volviendo a nuestro modelo cronológico, vamos a suponer que una de nuestras historias de usuario necesita aclarar una incertidumbre tecnológica porque no tenemos información suficiente para abordarla o ni siquiera para estimarla y puede poner en riesgo nuestro producto.

Deberíamos generar un Spike que nos ayude a resolver esta incertidumbre, a realizar esta prueba de concepto (PoC).

Ahora que tenemos clara cuál es la funcionalidad mínima que necesitamos en una primera instancia, podríamos considerar entonces que nuestro MVP se compone de:

• Una MMF, a través de la cual es necesario presentar 3 aspectos críticos a validar con los usuarios finales (3 historias). La tecnología existe y está probada, pero no sabemos cómo va a aceptar el usuario nuestra solución.
• Un Spike, o prueba de concepto, que requiere construir cierta funcionalidad. La tecnología es novedosa y desconocemos si su aplicación a nuestra solución será válida.

 

Estos cuatro items son las incertidumbres que necesitamos resolver. Sin hacerlo el riesgo de fracaso en nuestro proyecto sería alto, tanto por no saber cómo van a reaccionar los usuarios a nuestras funcionalidades, como por no saber si técnicamente es viable nuestra propuesta.

A la izquierda estaría representado este MVP.

 

 

 

Ahora que hemos visto como queda nuestro MVP, ¿qué pasa con nuestras siguientes historias de usuario? Recordemos que aún nos quedan 4 historias, dos que forman parte de nuestra épica y otras dos que no. Vamos a considerar que nuestro Spike ha ido correctamente y nuestro MVP también, es hora de iterar.

Vamos a considerar incluir la historia que generó el Spike y la otra que también formaba parte de la épica. Incluyendo también una de las historias que no formaban parte de la épica, podemos tener una agrupación de varias funcionalidades que sería entregable a nuestros usuarios, un MMR.

 

A la izquierda estaría representado este MMR.

 

 

 

 

 

 

 

Si recuperamos y añadimos la entrega anterior a nuestro diagrama «cronológico» para representarlo todo, tendríamos algo así:

Una nueva versión con varias funcionalidades que entregar a los usuarios (por lo tanto un MMR)

 

 

 

 

 

 

 

Nos quedaría por último una historia auto contenida que reflejar. Apoyándonos en que era auto contenida y era suficientemente relevante para nuestros usuarios, vamos a considerar una última versión o MMR, nuestros bloques de versiones quedarían así:

Solo nos quedaría una duda por despejar, ¿qué ha pasado con nuestra épica?

Sencillo, ha quedado distribuida en el tiempo, aportando lo más importante en iteraciones previas (MVP) y relegando características menos importantes a versiones posteriores (MMR1).

 

Con este marco, se cumple que una MMF tenga que ir completa en una release y que una Épica pueda estar distribuida a lo largo de varias releases.

 

Si extendemos este ejemplo un poco más, podríamos empezar a tener agrupaciones como las siguientes:

 

Solapamientos y “casos raros”

Teniendo en cuenta las definiciones originales y nuestro modelo de aplicación, podemos decir que:

• MVP – Minimum Viable Product, debe estar enfocado a realizar una «prueba de concepto», y mediante ésta validar una hipótesis o adquirir un conocimiento (sea de negocio o técnico).

• MMF  –  Minimum Marketable Feature, son las características mínimas con las que debe contar una funcionalidad para poder ser entregada a los usuarios finales.

• MMP (o MMR1)  –  Minimum Marketable Product, es la agrupación de MMFs que entregamos en la primera release. Es lo que comúnmente se confunde con MVP.

 

Extra bullet: ¿Minimum o minimal?

Me gustaría lanzar un último punto que afecta a los diferentes elementos que hemos estado viendo. En algunos casos aparece la definición minimal en lugar de minimum, pero es una diferenciación a nivel de matices, podemos considerarlo un «término de diccionario»en este caso. El uso más extendido y aceptado en minimum, por lo tanto, nos mantendremos apegados a éste.

• Minimum. Hace referencia a la cantidad estrictamente necesaria.
• Minimal.  Es algo más flexible y hace referencia a la cantidad que es suficiente.

 

Referencias

• El libro Lean UX, concretamente el capítulo 5 que hablan de los PMV (MVP).
• El libro Software by Numbers
• https://www.researchgate.net/publication/3248118_The_incremental_funding_method_Data-driven_software_development
• SaFE Features & Capabilities.
• La información del diccionario AgileAlliance
• https://disciplinedagiledelivery.com/defining-mvp/
• https://www.excella.com/insights/mvp-vs-mmf-whats-the-difference
• https://agilevelocity.com/product-owner/the-mmf-minimum-marketable-feature/
• http://agilismoeningenieriadesoftware.blogspot.com/2016/08/scrum-desarrollo-agil-desarrollo.html
• https://medium.com/@dblinov/minimal-viable-or-marketable-feature-product-or-release-b453f910f0f0
• https://en.wikipedia.org/wiki/Net_present_value