jueves, julio 02, 2020

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:
  1. Observa que no existe relación entre la cantidad de épicas y la cantidad de sprints.
  2. 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.
  3. 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.
  4. 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.
  5. 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:
  6. 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".
  7. 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.
  8. 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".
  9. El Inception consta de más actividades (ver un ejemplo acá -http://www.lecciones-aprendidas.info/2017/08/ejemplos-de-artefactos-agiles-inception.html )
  10. Estas historias de usuario no se escriben o refinan en el Inception, se detallarán más adelante. 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 volátil, 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." 
  11. 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 )
  12. 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

3 comentarios:

  1. Hola Jorge.
    Muchas gracias por este ejemplo tan detallado. Solo quiero preguntarte si este ejemplo o alguno similar esta o estará en el libro Historias de usuario: Una visión pragmática?. Saludos.

    ResponderEliminar
  2. Jorge Abad,
    Excelente detalle aplicado de SCRUM, muchas gracias.

    ResponderEliminar