![]() |
Granularidad de pila de producto |
Las últimas dos terceras partes de una pila demasiado grande seguramente vayan a cambiar en el futuro, y no vale la pena invertir esfuerzo en gestionar historias que sabemos que van a cambiar. Por otro lado una pila demasiado grande afecta seriamente a la capacidad para administrar las historias de usuario de valor, porque nos sumiremos en tratar con cientos de historias posiblemente irrelevantes o simplemente incorrectas o duplicadas. Lo más grave es que desviará nuestro foco del descubrimiento de nuevas historias de valor para nuestros clientes y no seremos capaces de actualizar las historias existentes a medida que obtengamos nueva información fresca.
No es inusual ver casos disfuncionales en los que la pila tiene más de 300 historias y el equipo que las construye tiene una velocidad media de 5 historias por sprints de dos semanas.
Una buen tamaño resulta en una parte superior de la pila de producto con 2 a 3 sprints de historias que cumplan con la definición de listo (DoR), y el resto de elementos que conformen la release en curso con elementos menos granulares en forma epics. La siguiente release debería de tener epics y temas, y las releases futuras solo grandes elementos como los son los temas.
![]() |
Las pilas anidadas que forman la pila de producto en el marco de SAFe |
Pila de equipo (Team Backlog): el tamaño de la pila queda limitado a las historias de usuario que el equipo haya incluido en la PI Planning para el siguiente PI, un periodo de tiempo de entre 2 y 3 meses. En mi experiencia estamos hablando de entre 20 y 40 historias de usuario.
Pila de programa (Program Backlog): un tren (ART) o tribu gestiona en su tablero Kanban aproximadamente tantas features como las que pudiera construir el tren en 3 PIs, un periodo correspondiente de entre 6 y 9 meses. En mi experiencia estamos hablando de entre 20 y 40 elementos, de los que entre 10 y 15 son pila del PI en curso.
Pila de solución (Solution Backlog): para los trenes de trenes, los Solution ART, los números en capabilities, muy grandes features, son similares.
Pila del portfolio (Portfolio Backlog): el tamaño dependerá de la pila con iniciativas estratégicas, o epics en SAFe, y dependerá de cuantas lineas de negocio cubra y cuantos trenes o personas estén asociadas a sus Value Streams. En un portfolio con un solo tren de unas 120 personas tiene sentido un tablero Kanban que gestione de 10 a 15 epics anuales y que tenga alrededor de 3 en curso; en un portfolio con trenes que sumen unas 2000 personas tiene sentido un tablero Kanban con alrededor de 150 epics anuales, con entre 30 y 40 en curso.
Estos números son números que he recolectado en diferentes clientes y experiencias, y que no pretenden ser nada más que para dar una idea aproximada.
![]() |
Ningúna pila visible para el equipo debe de tener más de un trimestre corrido de trabajo proyectado. Más sería desperdicio. Diana Larsen, del meetup "How do limits empower your Agility?" |
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
No hay comentarios:
Publicar un comentario