¿Hay algún patrón adecuado para escribir epics?

A/B Testing, una forma de validar una hipótesis
cortesía de Icons Icons

Recordemos que un epic se puede considerar como una superhistoria de usuario que se distingue por su gran tamaño, como una etiqueta que aplicamos a una historia grande cuyo esfuerzo es demasiado grande para completarla de una sola vez o en un solo sprint. A diferencia de las historias de usuario, que tienen baja granularidad, los epics tienen una alta granularidad y un alto grado de incertidumbre asociados. Realmente cualquier epic, e incluso una historia de usuario, no es más que una hipótesis; hasta que nuestro usuario la vea o la utilice y nos de feedback no sabremos si es la solución adecuada.

Desde este punto un epic lo podemos entender como una serie de experimentos, futuras historias de usuario, que construyen funcionalidad de forma incremental hasta llegar al resultado esperado. Esta forma de desarrollar epics ocurre como ciclo Lean Startup que mediante el desarrollo guiado por hipótesis, o hypothesis driven development (HDD), trata de desarrollar nuevas ideas, productos y servicios. A través de ciclo de feedback vamos validando nuestra hipótesis de manera que el Propietario del Producto gane comprensión sobre la solución más adecuada.

Como ejemplo está la técnica A/B Testing, que se utiliza en el ámbito del Marketing Digital y la Analítica web, que trata de identificar la mejor solución para un epic construyendo dos soluciones y realizando experimentos aleatorios con las dos variantes, A y B, siendo una la de control y la otra la variante. ¿No os ha pasado que lo que veis en Amazon en vuestro dispositivo es diferente a lo que ve vuestro compañero?

Barry O'Reilly popone el siguiente patrón en su artículo "How to Implement Hypothesis-Driven Development":

Creemos que [esta capacidad]

Resultará en [este resultado]

Tendremos confianza para proceder cuando [veamos una señal medible]

Patrón HDD de Barry O'Reilly

Creemos que [esta capacidad]

Responde a la pregunta ¿Qué funcionalidad desarrollaremos para probar nuestra hipótesis? Al definir la capacidad de una "prueba" del producto o servicio que estamos intentando construir, identificamos la funcionalidad y la hipótesis que queremos probar.

Resultará en [este resultado]

¿Cuál es el resultado esperado de nuestro experimento? ¿Cuál es el resultado específico que esperamos lograr al desarrollar la capacidad de "prueba"?

Tendremos confianza para proceder cuando [veamos una señal medible]

¿Qué señales indicarán que la capacidad que hemos construido es efectiva? Qué métricas predictivas clave (Leading Indicators) cualitativas y/o cuantitativas mediremos para proporcionar evidencia de que nuestro experimento ha tenido éxito y darnos suficiente confianza para pasar a la siguiente etapa.

Ejemplo de un epic de negocio escrito con este patrón:

Creemos que aumentar el tamaño de las imágenes de los restaurantes en la página de reserva

Resultará en una mejor participación y conversión del cliente

Tendremos confianza para proceder cuando

veamos un aumento del 5% en los clientes que revisan las imágenes de los restaurantes

y luego proceden a reservar en los próximos 2 minutos

My thanks to Barry O'Reilly on who I have based and who inspired me for this post :-)