Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor

Hola a todos

Debido a recurrentes conversaciones y aclaraciones sobre:

Épicas
Historias de Usuario
MVP (Minimun Viable Product o Producto Mínimo Viable)
Agregar Valor
Agregar Valor Incrementalmente
y Scrum

Voy a desarrollar un ejemplo hasta llegar a la planeación de los primeros tres sprints de un producto de solicitud de crédito, esto con el fin de ilustrar varios conceptos.

Comencemos.

Paso 1. Durante el Inception (9) se creó el siguiente User Story Map

Paso 2. Durante el Inception (9) se realiza la estimación de cada release

Se realiza una estimación de alto nivel y se identifica que aproximadamente (7) cada release tomará:

Release 1 - MVP	7 sprints
Release 2	6 sprints
Release 3	6 sprints

Paso 3. Inception - Durante el Inception se identifican las historias de usuario de los siguientes tres sprints (11)

El equipo técnico luego de tener conversaciones con el PO y los Stakeholders estima que las dos primeras historias épicas son suficiente para los primeros tres sprints, quedando identificadas de la siguiente manera:

Release	Épica	Historia de Usuario
Release 1 - MVP	Formato de solicitud básico	HU1 - Datos personales HU2 - Datos familiares HU3 - Datos laborales HU4 - Referencias laborales HU15-Información del cónyuge HU5 - Ingresos HU6 - Egresos HU7 - Bienes HU8 - Deudas HU9 - Tipo de crédito solicitado HU16 - Declaración de salud HU10 - Validación rápida contra base de datos interna HU11 - Validación de preaprobados
	Validar referencia personales	HU12 - Validar veracidad de referencias contra base de datos interna HU13 - Registro de llamadas a referencias dudosas HU14 - Escalar problemas a superior
	Validación centrales de riesgo 1 y 2	Pendientes por definir (10)
	Calificación	Pendientes por definir (10)
	Creación del crédito	Pendientes por definir (10)
	Desembolso a cuenta propia	Pendientes por definir (10)

Release	Sprint	Historia de Usuario
Release 1 - MVP	Sprint 1	HU1 - Datos personales HU2 - Datos familiares HU3 - Datos laborales HU4 - Referencias laborales HU15-Información del cónyuge
	Sprint 2	HU5 - Ingresos HU6 - Egresos HU7 - Bienes HU8 - Deudas HU9 - Tipo de crédito solicitado HU16 - Declaración de salud
	Sprint 3	HU10 - Validación rápida contra base de datos interna HU11 - Validación de preaprobados HU12 - Validar veracidad de referencias contra base de datos interna HU13 - Registro de llamadas a referencias dudosas HU14 - Escalar problemas a superior
	Sprint 4	Pendientes por definir (10)
	Sprint 5	Pendientes por definir (10)
	Sprint 6	Pendientes por definir (10)
	Sprint 7	Pendientes por definir (10)

Ya que llegaste hasta acá, déjame compartirte cuál es mi punto

Realmente no es un punto, son varios, veamos:

Observa que no existe relación entre la cantidad de épicas y la cantidad de sprints.
El sprint backlog identificado se mantuvo entre 5 historias aproximadamente, la experiencia de varios autores sugiere que un buen Sprint Backlog debería tener entre 6 - 10 historias de usuario de similar tamaño (en la medida de lo posible), menos no es recomendable.
El formulario o Épica de Solicitud de Crédito, NO ES UNA HISTORIA DE USUARIO, es una épica y el principal criterio es que un equipo se demorará más de un sprint en terminarlo (rompiendo los criterios de INVEST y CCC), por lo tanto, para ver progreso de VALOR INCREMENTAL, lo partimos en historias de usuario que nos permiten ver progreso en la construcción del formulario.
Obvio, cuando se termine el sprint 1 tal vez tengamos las historias: HU1 - Datos personales, HU2 - Datos familiares, HU3 - Datos laborales, HU4 - Referencias laborales, HU5 - Ingresos; pero no tendremos nada que liberar a producción, lo que si es cierto, es que habrá sofware funcionando potencialmente liberable (o en producción apagado) esperando el resto del MVP para ser liberado cuando el PO dé la orden.
El formulario o Épica de Solicitud de Crédito se terminará de construir aproxidamente en la mitad del sprint 3, como PO, ¿no prefieres ir observando progreso cada sprint? o ¿deseas luego de mes y medio (suponiendo que cada sprint fuera de 2 semanas) de estar comiendote las uñas, pensando que el equipo no te muestra avance? la verdad, creo que es mejor ver valor incremental; los PO con los que he trabajado luego de conocer el mundo del VALOR INCREMENTAL, de las pequeñas entregas, no desean volverse al anterior. Te invito a leer estos dos post respecto a la necesidad de tener historias de usuario pequeñas para poder observar progreso:

Cuando se termine el formulario o Épica de Solicitud de Crédito, se le agregará VALOR al producto, pero este valor no se hará tangible hasta después que se ponga en producción. Recuerda: "el Software solo adquiere valor cuando es usado".

Se dice aproximadamente, pues realmente no se sabe a ciencia cierta cuanto tiempo va a demorar en construirse cada release, lo que si sabemos es que vamos a estar priorizando por valor y tan pronto tengamos algo que genere impacto lo liberaremos.

Realmente se Agregará o Generará VALOR cuando salga a producción el MVP, antes solo se genera satisfacción al PO y a los stakeholders, pues estos ven progreso. Recuerda: "el Software solo adquiere valor cuando es usado".

El Inception consta de más actividades (ver un ejemplo acá -http://www.lecciones-aprendidas.info/2017/08/ejemplos-de-artefactos-agiles-inception.html )

Estas historias de usuario no se escriben o refinan en el Inception, se detallarán más adelantes. Se realiza en la vista del Discovery del Product Owner (ver http://www.lecciones-aprendidas.info/2020/03/product-owners-views-explicacion.html), además como estamos en un mundo tan volatil, es probable que tengan cambios en el futuro y sean fácilmente obsoletas. Recuerda, en ágil nos enfocamos mucho en no hacer activdades de desperdicio, o como dice el principio 10 del Manifiesto Ágil (clic aquí):"La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial."

Es altamente recomendado que como resultado de un Inception, se tengan las historias de usuario de los primeros tres sprints refinadas o preparadas para ser desarrolladas. Estas historias podrán tener formato o modo de representación que desees (ver http://www.lecciones-aprendidas.info/2019/05/modos-de-representacion-de-las-historias-de-usuario.html )

En caso que para el PO y los stakeholders sea de valor liberar la Épica-Solicitud de Crédito (tal vez, porque les ahorra muchos procesos manuales), aunque esta no sea el MVP, pueden hacerlo, (¿quién se los impide?), y para acabar de ajustar no es necesario esperar al review del tercer sprint para ponerla activa en producción, perfectamente pueden liberarla en la mitad, no es necesario que esperen (no te lo imaginabas, ¿cierto 🤯? ). La referencia a esta práctica de liberación continua en la guía de Scrum (ver acá), es la siguiente: "(Scrum se ha usado para) Liberar productos y mejoras tantas veces como sea posible durante el día".

Espero te sirva este post para el desarrollo tu producto y puedas aprovechar los beneficios del desarrollo incremental.

Hasta acá este compartir, bienvenido el feedback.

Saludos ágiles

Jorge Abad