¿Qué es una épica y qué no es?

2

Sé que lo más probable es que tú, lector, sepas de sobra lo que es una épica. Probablemente las has utilizado o las estás utilizando para gestionar y organizar tu backlog. Así que, ¿por qué me molesto en hablar sobre lo que todos ya saben? Por dos motivos: porque creo que hay gente que las usa mal y porque quiero dar una sorpresita al final del artículo.

Definición formal

Casi todas las definiciones formales coinciden en definir la épica como una gran historia de usuario, que podrá ser dividida en partes más pequeñas las cuales podrán ser entregadas en distintas iteraciones. Por ejemplo la definición de Agile Alliance es:

An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories

https://www.agilealliance.org/glossary/epic

Una épica es una historia de usuario que no puede ser entregada tal y como se ha definido dentro de una sola iteración, o que es suficientemente grande como para ser partida en historias de usuario más pequeñas.

El uso más común

Lo que más suelo ver, de cara a las épicas, a mi alrededor, es una agrupación de historias de usuario. En algunos casos es un componente que dura eternamente. Podríamos llamarlo un sub-producto. En otros casos son las fases en las que se ha pensado ir entregando el trabajo. He visto dividir la tecnología, con una épica Front, una épica Back y una épica BBDD. He visto una épica para todo lo que es incidencias. Y la mejor de todas, una épica por cada uno de los interesados que pedían las funcionalidades.

En todos los casos creo que el culpable es JIRA. JIRA te ofrece con las épicas una clasificación de “tickets” bastante potente. Así que cualquier necesidad de clasificación que tenga el equipo supone una tentación de usar épicas. Y es que Atlassian te las describe así:

Lo dicen claro, el objetivo es agrupar. Podría también ser una historia grande. Pero el objetivo principal es agrupar issues relacionadas.

Resumiendo, muchas veces veo las épicas, no como una entidad propia de la que “nacen” las historias, sino como una agrupación para poner orden a ese batiburrillo de issues que tiene el JIRA.

¿Qué opino yo?

Prefiero dejarlo claro, esto es mi opinión. No pretendo sentar cátedra, sino compartir lo que yo creo que debería ser una épica.

Una épica, como historia que es, representa una necesidad desde el punto de vista del usuario. Una gran nueva funcionalidad, un objetivo, un gran cambio, son candidatos a épicas.

Una épica no tiene por que ir ligada a una tecnología, a un producto, o si me apuras a un equipo. Una épica podría ser “Internacionalizar la plataforma de ventas” y que incluye conceptos como múltiples idiomas, monedas y distintas adaptaciones legales. El equipo del punto de venta, del back end, y el del ERP se podrían ver involucrados en esta épica.

Una épica nace de una necesidad de usuario muy grande, y posiblemente abstracta al principio. Las historias de usuario “nacerán” de esta épica. No es que las historias se agrupen y se “asocien” en una épica. Es la épica la que genera historias.

La épica representa un objetivo alcanzable. No es una línea de negocio, o un producto. Es un objetivo al que nos aproximaremos y que esperamos alcanzar algún día. Las épicas nacen, crecen, se reproducen creando historias y algún dia mueren. Son finitas en el tiempo. La épica puede versar sobre crear o cambiar una funcionalidad. La épica no es la funcionalidad.

Es decir, podemos tener una épica para “Internacionalizar nuestra plataforma de ventas”, pero no una épica de “Internacionalización” y que todo lo relativo a traducciones y monedas de ahora en adelante (hasta el infinito) vaya cayendo en la épica. Eso es un componente, no una épica.

¿Y a mí esto a qué me suena?

Estamos hablando de una tarea finita en el tiempo, que tiene un objetivo, con el que crearemos un producto o lo mejoraremos, … yo esto ya lo he oído antes.

Claro que lo he oído antes. Una épica es un proyecto. La gestiones como la gestiones, es un proyecto. Y no caigas en la tentación de pensar en un proyecto como “me obligan a planificarlo”, “requisitos”, “compromiso de entrega en tiempo”. Ya dije que un proyecto no tiene por qué significar todo eso. Repito que no hablo de como gestionarlo.

Por eso llevo tiempo pensando en cómo darle la vuelta al concepto de épica. ¿Qué partes de la gestión de proyectos pueden ser incorporadas a la gestión de una épica? Y no hablo de convertir a la épica en algo rancio. Hablo de que hay mucha sabiduría en esas técnicas del pasado. En otro artículo anterior comenté que hay esa manía de renegar de las técnicas del pasado y que hay mucho conocimiento que puede ser todavía muy útil.

No hablo de meter a un project manager. No hablo de hacer un presupuesto por épica. No hablo de calcular el valor ganado mediante EVM. Hablo de pequeños trocitos que se han olvidado.

En futuros artículos os hablaré de algunas de esas técnicas que se pueden incorporar con muy poco coste (algunas sólo suponen unos minutos por épica).

AgileSCRUM

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

2 comments

  1. Julio 5 febrero, 2019 at 09:07 Responder

    Gran jugada! Qué visión! 🙂
    Totalmente de acuerdo contigo con esto y con darle un giro a los malignos proyectos. Así que me dejas deseando leer el siguiente artículo.

    Por aportar algo diría:
    – La mayoría de épicas pueden ser un proyecto corto. No suelen durar mucho más 2-3 sprints. Aunque algunas se te pueden ir a medio año, pero son las menos.
    – La culpa no es de Jira, es de las personas. Y como tú mismo has dicho, Jira te da otras opciones para agrupar tareas. La de componentes es una, pero claro eso te obliga a definir componentes y es más fácil ir a salto de mata.

    Saludos!

Post a new comment