El sistema de cubos: estimar backlogs muy grandes
El sistema de cubos es el hermano más estructurado de la estimación por afinidad, diseñado para backlogs tan grandes que incluso el ordenamiento silencioso por espectro es demasiado lento elemento por elemento: piensa en portafolios con cientos de elementos, no docenas. En lugar de ordenar los elementos a lo largo de una línea continua, el equipo clasifica cada elemento directamente en uno de varios cubos etiquetados y numerados, en paralelo, con discusión reservada solo para los elementos que son genuinamente difíciles de ubicar. Esta página cubre cómo funciona y cuándo vale la pena recurrir a ella en lugar de la estimación por afinidad o Scrum Poker.
Cómo funciona
Se organiza una fila de cubos etiquetados, cada uno representando un tamaño; una escala común es 1, 2, 3, 5, 8, 13, 20, 40, 100, extendiendo las brechas al estilo Fibonacci habituales para cubrir un rango mucho más amplio de tamaños de elementos del que necesita un backlog de sprint típico. Cada participante toma una pila de elementos del backlog y los clasifica en cubos de forma independiente y en paralelo, no de uno en uno como grupo, sino con varias personas trabajando simultáneamente sobre el montón, de la misma forma que clasificar una baraja de cartas en palos va más rápido con varias personas que con una sola.
Los elementos que caen en el mismo cubo entre varios clasificadores no necesitan discusión; el grupo ya está implícitamente de acuerdo. Los elementos que distintos clasificadores ubican en cubos diferentes reciben una breve conversación, y el grupo se pone de acuerdo en un cubo. La mayor parte del backlog avanza sin ninguna discusión; el presupuesto de discusión se concentra por completo en los elementos genuinamente ambiguos.
Por qué escala más lejos que la estimación por afinidad
La fase de ordenamiento silencioso de la estimación por afinidad todavía procesa los elementos aproximadamente uno a la vez a lo largo de un espectro, incluso sin discusión, útil para docenas de elementos, pero el propio ordenamiento lineal se vuelve lento más allá de unos pocos cientos. El sistema de cubos paraleliza más a fondo: varias personas clasificando en un conjunto fijo de cubos simultáneamente, sin necesidad de acordar la posición exacta dentro de un cubo (solo cuál cubo), procesa un volumen mucho mayor en el mismo tiempo. Esta es la razón por la que la estimación a nivel de portafolio (cientos de elementos entre varios equipos o un roadmap de varios trimestres) recurre específicamente a cubos, no al ordenamiento por espectro.
Un ejemplo trabajado
Un programa con 300 elementos del backlog entre cuatro equipos necesita un pase de dimensionamiento aproximado a nivel de portafolio antes de la planificación trimestral. Cinco personas toman cada una una pila de aproximadamente 60 elementos y clasifican de forma independiente en nueve cubos etiquetados (del 1 al 100) durante unos 40 minutos. Una sesión de seguimiento compara los resultados: la mayoría de los elementos cayeron en el mismo cubo sin importar quién los clasificara, y el grupo dedica 20 minutos a discutir los aproximadamente 30 elementos que distintos clasificadores dividieron entre dos cubos adyacentes. 300 elementos dimensionados en aproximadamente una hora de esfuerzo total, un volumen que haría impráctico tanto a Scrum Poker como incluso a la estimación por afinidad.
Qué se sacrifica
El mismo compromiso que la estimación por afinidad, más pronunciado: casi ninguna discusión por elemento significa casi nada de la exposición de complejidad oculta que hace valioso a Scrum Poker. Un elemento puede caer con confianza en el cubo equivocado si el clasificador simplemente no sabe algo que un experto del dominio sí sabría, y a diferencia del espectro de la estimación por afinidad, donde un elemento mal ubicado es visualmente obvio junto a sus vecinos, un ordenamiento por cubos esconde ese error dentro de un cubo lleno de elementos de tamaño superficialmente similar. Esto hace que el sistema de cubos sea estrictamente una herramienta de triage de primer pase para un volumen que ninguna otra técnica puede manejar razonablemente, nunca un sustituto de la estimación real sobre trabajo que realmente está a punto de construirse.
Sistema de cubos vs. estimación por afinidad vs. Scrum Poker
| Sistema de cubos | Estimación por afinidad | Scrum Poker | |
|---|---|---|---|
| Mejor tamaño de backlog | Cientos de elementos | Docenas de elementos | Un puñado de historias listas para el sprint |
| Discusión por elemento | Casi ninguna | Mínima, solo en el pase de revisión | Completa, en cada historia |
| Paralelizable | Sí; muchos clasificadores a la vez | Parcialmente | No; un elemento a la vez |
| Produce un número listo para velocidad | Con las etiquetas de los cubos mismas | Necesita un paso de mapeo | Sí, de forma nativa |
| Etapa adecuada del cono de incertidumbre | Muy temprana, vaga | Temprana, vaga | Tardía, refinada |
Cuándo recurrir específicamente a los cubos
No todo backlog grande necesita el sistema de cubos; la estimación por afinidad maneja docenas de elementos con comodidad, y la estructura adicional de cubos numerados añade una sobrecarga de configuración que no vale la pena por debajo de unos pocos cientos de elementos. El sistema de cubos demuestra su valor específicamente en el volumen donde incluso el ordenamiento por espectro de la estimación por afinidad empieza a sentirse lento: portafolios multi-equipo, planificación anual entre docenas de épicas, o limpieza del backlog después de un largo periodo sin refinamiento regular.
Después del ordenamiento por cubos
Sin importar cómo un backlog grande obtenga su primer pase de dimensionamiento aproximado (cubos, afinidad, o de otra forma), los elementos que realmente van a entrar al próximo sprint todavía merecen una ronda real de Scrum Poker con discusión completa del equipo. Crea una sala gratis una vez que la parte superior de tu backlog esté refinada y lista.