Estoy trabajando para una agencia de desarrollo web. Asumo la responsabilidad de gestionar el trabajo que los desarrolladores de nuestra empresa realizan para nuestro cliente. Estamos usando JIRA para la gestión de tareas.
Las metodologías ágiles sugieren el uso de épicas para historias de usuarios que se pueden descomponer en otras más pequeñas. El problema es que el trabajo con el cliente probablemente será una asociación duradera, por lo que siempre hay novedades. Mi punto es que las épicas deberían ser finitas, pero en mi caso tienden a nunca terminarse porque siempre hay nuevas características que se agregan al sistema.
Ejemplos de epopeyas que uso incluyen:
Lista de contratos
Como usuario, debo poder listar y filtrar contratos, para que...
editor de contratos
Como usuario, debo poder editar contratos, para que...
Estas epopeyas parecen durar años. ¿Cómo podemos gestionar el alcance de estas epopeyas?
Siempre que sea posible, piense en las épicas como marcadores de posición para elementos más detallados de la cartera de productos, no como historias perennes. Es mejor agregar nuevas historias al Product Backlog a medida que se descubren o solicitan, en lugar de invitar a que el alcance se deslice mediante el uso indebido de épicas como generadores de trabajo permanentes del Product Backlog.
En metodologías ágiles, no entregas epopeyas o temas; usted entrega historias y tareas. En Scrum, también debe trabajar en iteraciones bien definidas donde el trabajo es lo suficientemente pequeño como para caber en un solo Sprint.
Cuando tienes una epopeya como:
Como usuario, debo poder listar y filtrar contratos, para que...
no es realmente procesable, ya que no cumple exactamente ninguno de los criterios de INVEST . En su lugar, debe utilizar sus ceremonias de refinamiento de tareas pendientes y planificación de Sprint para descomponer características específicas en historias de usuarios discretas.
Incluso si su épica es un elemento perenne en el que siempre está agregando nuevas funciones a las listas y filtros, cada historia dentro de la épica debe tener un alcance claro y estar bien definida antes de ser aceptada en el Sprint. Por ejemplo, durante el refinamiento de la cartera de pedidos, puede ver algunas solicitudes recientes relacionadas con su epopeya y agregar una historia como:
Como usuario,
quiero enumerar todos los contratos no vencidos por fecha de vencimiento
para poder ver cuáles están a punto de vencer.
o:
Como usuario,
quiero filtrar todos los contratos vencidos de la lista de tareas
para ver solo los contratos que aún son válidos.
Si bien es posible que ambas historias encajen dentro de su epopeya, probablemente sean lo suficientemente pequeñas como para caber dentro de un solo Sprint, es probable que se puedan probar y describan una propuesta de valor concreta.
El propietario del producto debe participar activamente para lograr que las partes interesadas identifiquen el trabajo como características discretas. Todo el Equipo Scrum debe participar para ayudar a descomponer las epopeyas e historias más grandes para que el PO pueda priorizarlas.
Concéntrese en entregar porciones pequeñas y funcionales en lugar de elementos de trabajo inestimables o abiertos. Si cambia su enfoque, descubrirá que está entregando características y valorando cada Sprint en lugar de llevar un albatros de forma épica alrededor de su cuello.
Si tiene demasiados problemas con Epic, le sugiero que mire sus historias y las vuelva a examinar.
La causa raíz parece deberse al hecho de que no está entregando valores trabajando en historias de usuarios, sino solo entregando épicas. (Estoy asumiendo esto)
Si ese es el caso, debe trabajar con su cliente para crear historias de usuario valiosas y pequeñas, lo cual es brutalmente difícil de hacer. De lo contrario, estarás en este bucle infinito una y otra vez y más y más...
Todd A. Jacobs