¿Cuál ha de ser el tamaño de una pila de producto?

Granularidad de pila de producto

Tener una pila de producto con un tamaño adecuado es esencial para una buena operativa. Una pila demasiado pequeña se "quema" demasiado rápido y existe el riesgo de que el equipo se quede sin historias de usuario y por tanto sin trabajo. Una pila demasiado grande implica que hay un montón de historias de usuario en ella que son irrelevantes y crean ruido.

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

Si nos hacemos la misma pregunta en un marco de escalado como SAFe® hemos de recordar primero que la pila de producto estará divida en varias pilas anidadas y mirar cada una de ellas:

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.