La semana pasada se lanzó una pregunta dentro del equipo muy interesante:
¿Qué es una historia épica?
La pregunta venía motivada, porque es una petición muy recurrente entre los usuarios de Taiga.
Mi respuesta en un correo fue esta:
Una épica, según los que lo inventaron, es una historia grande y muy indefinida que se va a dividir.
La Epic, tiene que desaparecer, en sus historias más pequeñas.
Historias de usuario que recuerdo deben seguir el patrón: INVEST
remarcando la I de «Independent» y la V «Valuable»
En mi opinión la EPIC puede tener sentido y ser visible, incluso con otro color, pero más reflejando ese estado de proto-historia, de idea sin madurar, de historia ‘gorda’… que como algo que vaya a ser parte de la estructura de la aplicación.
Preguntas que pueden surgir:
«Realmente todas las pequeñas historias no subirían solas a producción, están relacionadas»
Aquí puede ser útil el concepto de Epic, como agregador de us. Es decir, tenemos el concepto de módulo. Pero cuidado, esto generalmente es muy confuso de gestionar en cualquier plataforma, incluso en papel.
Hace al cliente muy difícil prioririzar, hay muchas dependencias.
Los tags aquí harían un buen trabajo, creo.
«Los prototipos de UX son para la historia grande, la epic»:
Eso es un problema de documentación, o de que el UX hace los prototipos antes de dividir, o que las divide back, con el sesgo que tiene, o todo a la vez.
Si las historias son independientes deberían tener su prototipo clarito. No rebuscar en el prototipo 17.0.3 y ver qué botón es la us que estamos mirando ahora.
«Pero las EPICs no son formas de agrupar los grandes bloques de un proyecto, por ejemplo API, Front Web, Front Movil, …»
No, eso se podrían llamar módulos o similar, pero esos módulos no tiene valor ‘per se’.
La palabra epic, la usa Mike Cohn en su libro, así que es ‘oficial’ 🙂
Busco en google y me encuentro este precioso artículo de Mike Cohn de este año hablando de todo esto!
http://kcy.me/1cu9f
que es una copia de éste del 2011
http://kcy.me/1cu9p
Espero que ayude. 🙂
Después de este correo tuvimos una reunión para definir:
«Qué sería una historia épica en Taiga»
Una de las máximas necesidades que tiene el usuario de una épica, es servir de base para el primer análisis y puede estar acompañada de un buen hilo de conversaciones, diagramas, wireframes e incluso prototipos. Y esa información no la queremos perder.
Si dividimos la épica en historias más pequeñas, ¿dónde metemos toda esa información previa?
Por lo que el formato final en Taiga, será una historia de usuario, que se marcará como ‘épica’ en sus propiedades, y se distinguirá de las demás en el backlog por el color.
La épica y sus historias derivadas estarán relacionadas y así podremos acceder a toda la información del análisis previo si fuera necesario.
Como bonus, esa agregación de historias en la épica, nos da la posibilidad de hacer un seguimiento de ver cuántas historias están hechas, y así tenemos algo parecido a un módulo o conjunto de historias que tenemos agrupadas.
Como bonus++, esas historias que salen de la épica, puede que no estén en el mismo proyecto, puede que estén en un subproyecto.
Esto abre la posibilidad de tener un proyecto ‘base’ que se llama ‘Dirección General’ una épica que se llama ‘Campaña de Navidad’ e historias de esta épica en el subproyecto de ‘Dpto. de Marketing’ como ‘Anuncios en Televisión’. Pudiendo seguir el avance de todas estas historias desde la épica.
¿Qué os parece? 🙂
Foto gracias a Kulawat Wongsaroj de su post Visualizing the Big Picture of your Agile Project
lifetime.day.each() { enjoy() } 