Probablemente hayas escuchado los términos Épico, Historia y Tareas, ¿verdad? Hay mucha confusión con estos términos. Vayamos a sus definiciones:
Backlog del Producto – Product Backlog (PB)
Es el conjunto de todas las necesidades de los consumidores y del negocio que el producto resolverá. Se mantiene valorado y priorizado por el Product Owner. No es obligatorio usar el formato de Historia de Usuario en el Product Backlog.
Épico (Epic)
Es una historia de usuario que aún no se ha detallado, es demasiado grande o todavía presenta mucha incertidumbre y, por lo tanto, no se puede transformar en un incremento del producto. Lo épico debe rebanarse en historias de usuarios más pequeñas. Un ejemplo de épico podría ser: Yo, como una persona con discapacidad visual, quiero que mi entorno de trabajo sea más accesible para que no depender tanto de otras personas.
Historia de usuario (User Story - US)
Tratamos la historia de usuario en los artículos ¿Qué es User Story? ¿Cómo es User Story? e Historia de Usuario: Evitando Disfunciones.
En resumen, la Historia de Usuario es un formato sucinto para escribir los requisitos necesarios para construir un producto. Debe ser comprensible para los clientes y consumidores. Ejemplos de historias de usuarios para el ejemplo épico presentado anteriormente:
Historia 1: Yo, como una persona con discapacidad visual, deseo que los lugares a los que tengo que ir sean accesibles para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los quiero ir.
Historia 2: Yo, como una persona con discapacidad visual, quiero llegar fácilmente a la salida de emergencia, porque no quiero morir en un incendio.
Ten en cuenta que un buen Product Owner puede rebanar la historia aún más si intenta comprender la parte más importante del problema más importante del cliente más importante. Por ejemplo:
Historia 1.1: Yo, como una persona con discapacidad visual, quiero llegar fácilmente al cuarto de baño para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los que quiero ir.
Historia 1.2: Yo, como una persona con discapacidad visual, quiero llegar fácilmente a los ascensores para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los que quiero ir.
Historia 1.3: Yo, como una persona con discapacidad visual, quiero llegar fácilmente a las salas de reunión para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los que quiero ir.
Puedes rebanar aún más. Digamos que la mayoría de las personas con discapacidad visual están en el quinto piso.
Historia 1.1.1: Yo, como una persona con discapacidad visual que trabaja en el quinto piso, quiero llegar fácilmente al cuarto de baño para no tener que pasar por la vergüenza de preguntarle a la gente sobre los lugares a los que quiero ir.
Tareas (Tasks)
Las tareas son elementos técnicos necesarios para que una Historia de Usuario se transforme en un incremento del producto. Ejemplo de tareas de la Historia 1.1.1:
- Adquirir un módulo de sensor de presencia;
- Adquirir altavoces;
- Diseñar las nuevas placas;
- Crear modelos de ingeniería;
- Montar las placas;
- Instalar las placas en los cuartos de baño del quinto piso, etc.
Jerarquía
La jerarquía que tenemos con las historias de usuario es esta:
- Backlog del Producto
- Épico
- Historia de Usuario
- Tareas
El Backlog del Producto es la colección de historias de usuarios que deberemos hacer. Un backlog del usuario tiene de 1 a N Historias. El backlog no tiene que contener épicos. Por lo general, los equipos que trabajan con un objetivo totalmente flexible y una validación constante de hipótesis mantienen un backlog extremadamente reducido.
Si hay épicos en el backlog, puede rebanarse en N historias de usuarios. Sin embargo, lo épico puede ser descartado si se concluye que no será capaz de traer los beneficios inicialmente imaginados.
Una historia de usuario se puede dividir en N tareas técnicas. No obstante, cuando el Product Owner hace una buena rebanada de las historias de usuarios, el Equipo tiene un flujo de valor muy bien mapeado en la Pizarra de Tareas, ya domina las herramientas y técnicas necesarias para la construcción y conoce el contexto en el que trabaja, menor es la necesidad de dividir las historias en tareas.
Conceptualmente sólo existen estos cuatro niveles en la jerarquía de historias de usuarios, pero hay mucha confusión. Una buena parte de esto se genera cuando las personas comienzan a usar herramientas de gestión de proyectos ágiles antes de conocer los conceptos.
Confusión generada por la nomenclatura de las herramientas
La siguiente tabla muestra algunos de los nombres utilizados por las herramientas más conocidas en el mercado: C.A. Agile Central (anteriormente Rally), Jira, IBM Rational Team Concert (RTC), Trello y VersionOne. En la imagen podemos ver que hay una estandarización y esto termina generando una gran confusión en las personas.
CA Agile Central
- Tema (Producto)
- Iniciativa (Producto)
- Funcionalidad (Épico)
- Historia de Usuario Épico (Épico)
- Historia de Usuario (Historia de Usuario)
- Tareas (Tareas)
Jira Software
- Proyecto (Producto)
- Épico (Épico)
- Historia de Usuario (Historia de Usuario)
- Tarea (Historia de Usuario)
- Subtarea (Tareas)
IBM Rational Team Concert (RTC)
- Proyecto (Producto)
- Épico (Épico)
- Historia de Usuario (Historia de Usuario)
- Tareas (Tareas)
Trello
- Pizarra (Producto)
- Tarjeta (Historia de Usuario)
- Checklist (Tareas)
VersionOne
- Programa (Producto)
- Proyecto (Producto)
- Release (Producto)
- Historia de Usuario (Historia de Usuario)
- Tareas (Tareas)
Algunas de estas herramientas tienen el principio del control en la cartera de proyectos. Algunas aceptan personalización tanto de nombres, como de estructuras. Por eso, si tu compañía usa alguna de ellas, puedes tener una jerarquía diferente a la que se presenta aquí. Para algunas de ellas como IBM Rational Team Concert (RTC), todo es un elemento de trabajo. Puedes o no tener épicos, puedes o no tener subtareas, etc.
Conclusión
Algunos conceptos de Métodos Ágiles pueden ser difíciles cuando estamos comenzando. Principalmente si venimos del mundo de la Gestión de Proyectos. Con el tiempo nos acostumbramos a nuevos conceptos.
¿Todavía tienes alguna duda sobre este tema? Déjala en los comentarios.
Aprovecho la oportunidad para invitarte a participar en nuestra formación de Certified Scrum Product Owner (CSPO) y aprender en la práctica cómo crear buenas historias de usuario.
Consulta también nuestro blog para acceder a más artículos sobre el rol del Product Owner.
