Epics ágiles: definición, ejemplos y plantillas

Resumen: un epic ágil es un conjunto de trabajo grande que puede dividirse en tareas específicas (denominadas “historias de usuario”) en función de las necesidades o solicitudes de los clientes o usuarios finales. Los epics son una práctica importante para los equipos ágiles y de DevOps.

Al adoptar una metodología ágil y DevOps, un epic permite gestionar tareas.Se define como una gran cantidad de trabajo que se segmenta en tareas específicas (llamadas “historias” o “historias de usuario”) en función de las necesidades/solicitudes de los clientes o usuarios finales.

Los epics constituyen una forma útil de organizar el trabajo y de crear una jerarquía. La idea es desglosar el trabajo en elementos que se puedan lanzar, de manera que los proyectos grandes se puedan llevar a cabo efectivamente y tú puedas continuar proporcionando valor a tus clientes con regularidad. Los epics ayudan a los equipos a desglosar su trabajo y, al mismo tiempo, a seguir trabajando en pos de una meta más elevada.

Mantener la agilidad a la hora de organizar tareas de gran envergadura como los epics no es tarea fácil (nunca mejor dicho). Sea cual sea el tamaño de tu organización, descubrir cuál es la relación que tienen los epics con unas prácticas sólidas de metodología ágil y DevOps constituye una destreza esencial.

Un epic es una gran cantidad de trabajo que se puede desglosar en varias historias de menor tamaño, a veces denominadas "incidencias" en Jira. Los epics suelen abarcar a varios equipos en varios proyectos, y puede incluso hacerse un seguimiento de ellos en varios tableros.

Los epics casi siempre se entregan a lo largo de una serie de sprints. A medida que un equipo aprende más sobre un epic a través del desarrollo y los comentarios de los clientes, se irán incorporando y eliminando historias de usuario según convenga. Esa es la clave de los epics ágiles: el alcance es flexible, y se basa en los comentarios de los clientes y en la cadencia del equipo.

Pongamos que es el año 2050 y trabajamos para una organización de viajes espaciales de ocio. Efectuamos alrededor de una docena de lanzamientos al año, así que ninguno de estos lanzamientos es lo más grande que hacemos en un año, pero siguen distando mucho de ser una tarea rutinaria y requieren muchas horas de trabajo. Semejante volumen resulta ideal para un epic.

Ejemplo de epic: "Lanzamiento de turismo espacial para marzo de 2050" incluye historias de elementos de trabajo rutinarios, así como otras destinadas a mejorar aspectos clave del lanzamiento del transbordador, que pueden abarcar ámbitos muy diversos, desde la compra de billetes de viajes espaciales por parte de los clientes hasta el lanzamiento del propio cohete. Por lo tanto, varios equipos contribuirán a este epic trabajando en una amplia gama de historias.

El equipo de software que respalda la compra de billetes para el lanzamiento de marzo de 2050 podría estructurar su epic como se indica a continuación:

Al mismo tiempo, los equipos de propulsión podrían contribuir al mismo epic con estas historias:

Un epic debería ofrecer al equipo de desarrollo todo lo que sus miembros necesitan para tener éxito. Desde un punto de vista práctico, es la máxima categoría de su jerarquía de trabajo. Sin embargo, comprender cómo se relaciona un epic con otros elementos ágiles proporciona un contexto importante para el trabajo de desarrollo diario.

• Una hoja de ruta de un producto es un plan de acción de cómo un producto o una solución evoluciona a lo largo del tiempo.
• Un tema es un objetivo de la organización en el cual se inspiran los epics y las iniciativas.
• La hoja de ruta de un producto se expresa y visualiza como un conjunto de iniciativas organizadas en un cronograma.
• Desglosar iniciativas en epics ayuda a mantener el trabajo diario del equipo (que se expresa en historias más pequeñas) conectado a los objetivos de la empresa generales.

Un conjunto de epics completados impulsa una iniciativa específica, que hace que el producto en general continúe desarrollándose y evolucionando al compás de las demandas del mercado y de los clientes, así como de los temas de la organización.

Si volvemos al ejemplo anterior, uno de los temas podría ser aumentar los lanzamientos de transbordadores espaciales, la hoja de ruta se encaminaría a incrementar el número de lanzamientos trimestrales de 3 a 4, las iniciativas consistirían en reducir los costes y vender más billetes, y cada epic pasaría a formar parte de las iniciativas.

Cuando crees un nuevo epic, ten en cuenta otras herramientas de planificación y organización de las que es posible que ya disponga el equipo. La creación de epics basándote en los objetivos y resultados clave trimestrales del equipo es un buen comienzo. Cuando crees un epic, piensa en lo siguiente:

• Creación de informes: crea epics para los proyectos que querrán tener controlados los gerentes y ejecutivos.
• Narración: usa epics y las historias que surgen en ellos como mecanismo para contar cómo llegaste al estado actual de una función o un producto.
• Cultura: deja que la cultura de la organización dicte el tamaño y el nivel de detalle de un epic.
• Tiempo: la mayoría de equipos de desarrollo dependen de marcos de estimación en lugar del tiempo, pero merece la pena asegurarse de que los epics tendrán un par de semanas de duración. Ni demasiado tiempo ni demasiado poco.

Descubre cómo funcionan los epics en Jira.

Desglosar un epic en historias más prácticas ayuda a comprender un proyecto y a mantener la motivación, pero puede ser una tarea abrumadora para los novatos. No hay una solución universal para la creación de historias a partir de un epic, pero hay muchas buenas opciones que puedes considerar:

• Función de usuario o perfil: crea una historia independiente para cada perfil de usuario. “Inicio de sesión más rápido para nuevos usuarios”, “inicio de sesión más rápido para clientes que vuelven”, etc.
• Pasos ordenados: desglosa el proceso y crea una historia para cada paso.
• Cultura: deja que las normas del equipo dicten si una historia es una tarea rápida o un proyecto de una semana completa.
• Tiempo: a menos que haya alguna otra convención preestablecida, diseña historias que puedan completarse en un sprint o menos.

No existe ninguna definición universal que establezca una distinción clara entre una historia de gran tamaño y un epic. En general, debería considerarse como epic cualquier volumen de trabajo que el equipo calcule que tardará "semanas" (o más) en terminar (en lugar de "horas" o "días") y, como tal, debería desglosarse en historias más pequeñas.

Se pueden usar gráficas de trabajo pendiente para visualizar los epics y, además, estas sirven para mantener a los equipos motivados y a las partes interesadas ejecutivas informadas. Una buena gráfica de trabajo pendiente de un epic es donde la agilidad de la organización brilla con verdadera luz propia.

La gráfica de trabajo pendiente de un epic muestra la cantidad estimada y real de trabajo que hay que hacer en un sprint o un epic. El eje de abscisas indica el tiempo, mientras que el de ordenadas representa las historias o las incidencias.

Utiliza la gráfica de trabajo pendiente para hacer un seguimiento de todo el trabajo restante y para determinar las probabilidades de cumplir el objetivo del sprint. Supervisar el trabajo total restante a lo largo de la iteración permite al equipo gestionar su progreso y responder en consecuencia.

Al analizar una gráfica de trabajo pendiente queda claro cómo progresa el equipo y dónde están los impedimentos. La posibilidad de ver con claridad estos datos mantiene a todo el mundo en sintonía y promueve un diálogo abierto sobre la evolución del producto y las previsiones de finalización. ¡Por no mencionar que la transparencia genera confianza!

Descubre cómo configurar gráficas de trabajo pendiente en Jira

Cuando domines el arte de crear epics e historias, quizá quieras ir más lejos y optimizar procesos con la automatización. En Jira, estas son tres de las reglas de automatización más habituales para sprints.

1. Añade automáticamente 3 historias tras la creación de un epic. Ir a la regla.
2. Cierra automáticamente historias cuando el epic se marque como finalizado. Ir a la regla
3. Cambia el estado de un epic cuando cambie el estado de una de las incidencias vinculadas. Ir a la regla

Consulta estas reglas de automatización y centenares más en la Biblioteca de plantillas de Jira Automation.

Ir a la biblioteca

Los epics no son los cimientos indiscutibles de un programa de metodología ágil, pero sí representan en la práctica el eje motor de la mayoría de los equipos ágiles y de DevOps.Comprender dónde encajan en un programa de metodología ágil sólido crea el contexto necesario para tu trabajo, y desglosarlos en historias da impulso al proyecto.