#ScrumClinic: Historias épicas

Es habitual que lectores del blog y alumnos de los cursos de Scrum y cursos de Kanban me escriban para preguntarme dudas sobre la forma en la que implementan Scrum y Kanban en sus organizaciones. Hasta ahora, siempre he respondido en privado. Estas ideas se agrupan en dos secciones: #ScrumClinic y #KanbanClinic. Si tienes una consulta, mandala a través del formulario de contacto

Hace unos meses me escribió Esther Moreno, UX Designer de Kaleidos, preguntándome por una nueva feature que iban a implementar en Taiga. Esther ha publicado su investigación completa en el blog de Taiga.

¡Muy buenas!

El contexto es que vamos a incorporar Epics en Taiga. Es una funcionalidad que la piden muchísimo así que es importante hacerla bien y flexible para que sirva para todos. Y claro, necesito saber cómo trabaja la gente con epics, cuáles son sus necesidades, sus dificultades, lo que valoran y lo que no.

Para esto, lo que me gustaría es que nos contases cuál es tu proceso de trabajo detallado en cuanto a epics (por ejemplo: creamos epics desde el primer momento, le asignamos los puntos, se la asignamos a la persona de ux, luego se dividen,…).

Además de contar el proceso, me gustaría que respondieras a 3 o 4 preguntas muy concretas si es posible:

1. ¿Debería pasar la tarjeta de la epic al sprint?
2. ¿Debería estar en kanban con las user stories?
3. ¿Una epic tiene identidad propia o es una «user story del tipo epic»? Por decirlo de otro modo ¿Creas una epic desde el principio o creas una user story y luego le dices que es una epic?
4. ¿Una user story puede pertecer a 2 epics?

Muchas gracias!!!!

¿Debería pasar la tarjeta de la epic al Sprint?

No, las epics están más cerca de la estrategia que de la implementación táctica. El Sprint es táctico, no estratégico, añadir la tarjeta al Sprint solo añadiría ruido, y el equipo debería de entender como las historias se relacionan con las épicas a través del Sprint Goal, que son objetivos de negocio.

¿Debería estar en kanban con las user stories?

No, por la misma razón de arriba. Las únicas tarjetas que se mueven en el Scrum board son las tareas que crea el equipo -los Product Backlog Ítems, sean User Stories u otra cosa se mantienen fijas, ya que son la cabecera del carril.

Además, el Development Team puede añadir o eliminar tareas del Scrum board a voluntad. El Scrum board puede ser un tablero Kanban, aunque Scrum solo dice que hay que visualizar el trabajo del Sprint backlog, no dice cómo.

Implementar un sistema kanban puede limitar la auto-organización del equipo de desarrollo, uno de los pilares de Scrum -y por los que los desarrolladores pueden rechazar el uso de una herramienta concreta-.

¿Una epic tiene identidad propia o es una «user story del tipo epic»?

Ambas cosas pueden pasar. Puedes crear una epic desde el principio o puedes crear varios Product Backlog Items y agruparlos en un epic -ten en cuenta que el product backlog contiene Product Backlog Items, que pueden ser User Stories u otro tipo de item-. Te adjunto una imagen para que entiendas como se relacionan los distintos ítems que puede haber en un product backlog con la estrategia, la táctica, el story mapping, la implementación y el modelado de negocio.

¿Una user story puede pertecer a 2 epics?

No, pero pueden existir dependencias. Es decir, aunque no pueda pertenecer a dos épicas, puede que exista una épica que dependa de que se implemente una user story que pertenece a otra épica.

Entendiendo las epic user stories dentro de un marco del valor de negocio

Uno de los problemas al que se enfrentan Product Owners y Product Managers es entender donde encajan las historias épicas dentro de su estrategia de producto. Algunos de ellos las utilizan como recordatorio de que algo más grande está pasando, otros para mantener la coherencia de desarrollo y otros, simplemente, porque están en JIRA.

Hay que mirar a las épicas desde una perspectiva estratégica más global. Durante el curso de Product Owner, los alumnos aprenden cómo ir desde una visión estratégica de un producto apoyada en un Business Model Canvas, a la elaboración de un Sprint Goal y un primer grupo de Product Backlog Ítems candidatos a ser implementados en un sólo Sprint.

Pensemos en un martillo. Si sólo tenemos en cuenta la perspectiva del martillo, en realidad puede servir para muchas cosas. Clavar clavos y romper dedos. Sujetar la pata de una mesa y quitar los mismos clavos. Las historias de usuario, épicas o no, cumplen una función dependiendo de cual sea nuestras estrategia de producto.

En la imagen de arriba, se ven varios métodos de organización del Product Backlog. Las historias épicas serviran a cada uno de ellos de manera distinta, con distintos resultados. La siguiente imagen da una mejor perspectiva del asunto.

Las historias épicas se encuentran a medio camino entre el ¿Por qué? de nuestro producto, el ¿Cómo? y el ¿Qué?. Nuestra facilidad o dificultad a la hora de especificarlas dentro de nuestro entorno particular es un indicador de qué nos falta y qué nos sobra.

Habitualmente, lo que falta es una visión clara del producto y lo que sobra son detalles de especificación. Por eso, disponer de herramientas como Lean Startup o Lean UX nos facilitaran el trabajo cuanto más a la izquierda de la imagen, mientras que Specification by Example nos ayudará en definir concretamente qué queremos implementar.

Dos lecturas fundamentales para entenderlas mejor

User Stories Applied

Mike Cohn

Este libro es uno de los básicos de cualquier biblioteca ágil. Mike hace un recorrido práctico sobre la escritura de historias de usuario y su aplicación dentro del día a día de un equipo Scrum. A pesar de tener 14 años, sigue siendo la referencia para Product Owners.

Hay que pensar que este libro está escrito desde la perspectiva de XP y de Scrum. En 2004, la Scrum Alliance acababa de nacer y estos dos métodos todavía estaban muy ligados.

Comprar User Stories Applied en Amazon

User Story Mapping

Jeff Patton

En este libro, Jeff Patton pone el foco en llevar el valor desde una visión de producto hasta la creación del backlog a través de la técnica de User Story Mapping. Evaluando las ventajas e inconvenientes, y describiendo los principales problemas de esta técnica, Jeff consigue en un libro ameno y fácil de leer introducirnos en esta herramienta.

Si compráis la versión digital, os beneficiaréis de las actualizaciones frecuentes que Jeff ha ido incluyendo en el libro desde su lanzamiento.
Comprar User Story Mapping en Amazon