Cómo dividir Epics
Un Scrum Trainer me pidió hace poco algunos buenos ejemplos de cómo dividir grandes User Stories (Epics) en historias más pequeñas. Me gustaría compartir estos ejemplos contigo.
Epic 1: Encontrar la campaña de marketing correcta
El primer ejemplo trata de una empresa que vende software a grandes cadenas minoristas (WalMart, etc.). El director del departamento de marketing tenía que decidir cómo gastar el presupuesto de publicidad. Por eso, la User Story (Epic) se escribió desde su perspectiva. Su primer gran objetivo era:
Como director del departamento de marketing, quiero poder revisar las campañas publicitarias anteriores para identificar y repetir las campañas más rentables.
Los miembros del equipo dijeron que esto era claramente un Epic. Así que les pedí que crearan varias historias más pequeñas:
1a: Como director del departamento de marketing, quiero poder seleccionar un período de tiempo del que provengan las campañas publicitarias a revisar, para que...
2a: Como director del departamento de marketing, quiero poder elegir qué campañas (correo directo, TV, email, radio, etc.) se incluyan en la revisión, para que...
(Observa que he numerado las historias de forma que se pueda ver de cuál historia original provienen. En un proyecto real, no lo haría necesariamente, a menos que tenga una herramienta que lo haga automáticamente.)
No sabía exactamente qué tan grandes eran estas dos historias y si debían dividirse aún más. Así que pregunté al equipo: "Si tuvieran que estimar estas historias, ¿qué unidad les vendría primero a la mente? ¿Horas, días, semanas, meses o años?" Para 1a fueron días, así que la historia se quedó como estaba. Para 1b fueron semanas, por lo que dividimos la historia una vez más:
1b1: Como director del departamento de marketing, quiero poder ver información de correos directos de campañas anteriores, para que...
1b2: Como director del departamento de marketing, quiero poder ver información de publicidad en TV de campañas anteriores, para que...
1b3: Como director del departamento de marketing, quiero poder ver información de campañas anteriores con publicidad por email, para que...
etc.
Cada una de estas historias tenía un buen tamaño ("estimaríamos esta historia en días"). Sin embargo, necesitaban cierta información adicional: las llamadas "Conditions of Satisfaction", que son básicamente pruebas de aceptación de alto nivel. Para 1b2, los miembros del equipo escribieron lo siguiente en el reverso de la tarjeta:
¿Cuántos espectadores de qué rango de edad hubo?
¿Cuántos espectadores de qué rango de ingresos hubo?
Ejemplo 2: Maximización de ingresos de un hotel
En este ejemplo se trata de un hotel donde se quería maximizar los ingresos, es decir, el operador quería encontrar el precio más alto posible para las habitaciones. Los precios se calculaban en base a varios factores. Estos eran, por ejemplo, los precios de habitaciones de hoteles comparables, la temporada, grandes eventos en la zona cercana (cuando se celebra un Super Bowl o un campeonato mundial en una ciudad, los precios suben), etc.
Esta fue la User Story original (Epic):
1: Como hotelero, quiero encontrar el precio óptimo para mis habitaciones.
Por simplicidad, asumamos que el hotel solo tiene una categoría de habitaciones. Como ya se mencionó, muchos factores pueden influir en el precio de una habitación de hotel. La fórmula básica para calcular el precio de la habitación sería:
Precio de habitación = f (a,b,c...)
Esta función depende de varios factores. Para cada uno de ellos hay una historia:
1a: Como hotelero, quiero determinar el precio óptimo para mis habitaciones en base a los precios del año pasado.
1b: Como hotelero, quiero determinar el precio óptimo para mis habitaciones en base a los precios de hoteles comparables.
La historia 1a solo dice que los precios del año anterior se consideran en la función. La historia 1b dice que los precios que cobran otros hoteles también se incluyen en el cálculo.
Cada una de las historias era bastante grande (un Epic) y, por supuesto, había más de las dos mencionadas arriba. Por lo tanto, habría sido imposible incluirlas todas en un solo Sprint. Las historias se implementaron gradualmente y así la fórmula mencionada daba un precio incorrecto, ya que se construía de la siguiente manera:
Precio de habitación = f (a)
luego
Precio de habitación = f (a,b)
luego
Precio de habitación = f (a,b,c)
etc.
Después del primer Sprint, el cálculo sería Precio de habitación = f (a) y se obtendría un precio incorrecto (que no se puede pasar al cliente). Sin embargo, el cálculo en sí es básicamente correcto. Quizás los valores para (b) y (c) están codificados directamente o simplemente se ignoran. Pero de esta manera, tales algoritmos complejos pueden construirse de forma incremental.
Como la historia 1b seguía siendo demasiado grande, se dividió nuevamente:
- 1b1: Como hotelero, puedo definir un cierto número de hoteles comparables. (Para esto se usó el término "Comparable Set" en esta empresa.)
- 1b2: Como hotelero, puedo añadir hoteles al Comparable Set.
- 1b3: Como hotelero, puedo eliminar hoteles del Comparable Set.
- 1b4: Como hotelero, puedo borrar un Comparable Set completo que ya no necesito.
- 1b5: Como hotelero, me oriento por los precios de las habitaciones de los hoteles de un determinado Comparable Set para determinar mis precios.
Estas son dos historias adicionales:
- 1c: Como hotelero, quiero ajustar el precio óptimo de mis habitaciones según la ocupación prevista.
- 1d: Como hotelero, puedo establecer parámetros que influyan en el precio óptimo, como la ocupación deseada, la ocupación mínima y la ocupación máxima (podría superar el 100%).
Conclusión sobre la división de Epics
Casi todos los equipos tienen problemas al principio para dividir correctamente las User Stories. Por experiencia, en algún momento dentro del primer año se produce un "clic" y los miembros del equipo saben cómo dividir las historias específicamente para su área y sus proyectos. Si aún no estás familiarizado con Agile o las User Stories, sigue adelante: ¡con el tiempo se vuelve más fácil!
