T-shirt sizing ágil: cómo estimar el esfuerzo en equipo

Tu equipo tiene 30 elementos del backlog que dimensionar, una ventana de 60 minutos y una decisión de roadmap que depende del resultado. Debatir si una historia es un 5 o un 8 no cabe ahí. El t-shirt sizing ágil es una forma más rápida de llegar a una visión compartida del esfuerzo, y es más preciso de lo que su sencillez sugiere.

Qué es el t-shirt sizing ágil

El t-shirt sizing asigna a cada elemento de trabajo una etiqueta de talla (XS, S, M, L, XL, a veces XXL) en lugar de una estimación en horas o días. El grupo recoge a la vez esfuerzo, complejidad e incertidumbre. Nadie debería leer el resultado como una previsión literal.

La técnica se basa en una observación sencilla: a las personas se nos da mucho mejor comparar cosas entre sí que juzgar valores absolutos de forma aislada. La guía de estimación ágil de Atlassian apunta algo parecido: usar story points en lugar de horas fomenta la colaboración del equipo, reduce el sesgo emocional y mejora las previsiones. «¿Esto es una S o una M?» se responde más rápido, y con menos errores, que «¿cuántas horas llevará esto?».

El t-shirt sizing encaja en el refinamiento temprano del backlog, la planificación del roadmap y la PI Planning en contextos SAFe, donde las épicas y las features necesitan una talla rápida antes de que nadie las desglose. Un equipo de producto que dimensiona así durante las revisiones trimestrales del roadmap puede repasar todo el trabajo de un trimestre en una sola sesión, porque cada elemento lleva un par de minutos en lugar del debate más largo que invita el planning poker. Con 30 o más elementos sobre la mesa, esa diferencia se acumula rápido.

Cómo facilitar una sesión de t-shirt sizing

Una sesión tiene cinco fases.

• Preparación: quien facilita comprueba que cada elemento del backlog tenga contexto suficiente para un debate útil. Si una historia tiene un título de una línea y ningún criterio de aceptación, el equipo pasará 10 minutos adivinando de qué se trata antes de poder dimensionarla. Haz que los elementos se entiendan antes de la sesión.
• Anclaje: antes de votar, el equipo acuerda una historia de referencia para cada talla. Es el paso que los equipos se saltan más que ningún otro. Sin una referencia compartida, «M» significa algo distinto para cada participante. Elige una historia terminada por talla que todo el mundo acepte, y mantén esos ejemplos visibles durante toda la sesión, en un tablero de Miro, una página de Confluence o una tarjeta física. Funcionan como una regla, y deciden si el equipo se mantiene calibrado o empieza de cero en cada sesión.
• Revelación simultánea en silencio: cada persona anota una talla en privado y todos la revelan a la vez. Nadie habla antes de la revelación, para que la primera voz de la sala no ancle a las demás.
• Debate: debate solo los valores atípicos. Si todo el mundo dice M y una persona dice XL, vale la pena tener esa conversación. Si la dispersión es M y L, elige una y sigue adelante. Las sesiones se desmoronan cuando los equipos debaten a fondo cada pequeña diferencia.
• Registro del consenso: introduce la talla acordada en la herramienta del backlog antes de pasar al siguiente elemento.

Para equipos remotos, las plantillas de estimación ágil de Miro y tableros digitales similares hacen posible la revelación simultánea con una sola acción de «voltear todo». La herramienta tiene que hacer cumplir la regla. Si los participantes escriben sus respuestas en un documento compartido visible, leen las respuestas de los demás antes de comprometerse, y el sesgo que querías evitar vuelve.

Si fijas las historias de referencia en una página compartida de Confluence, las personas nuevas del equipo pueden aprender qué significa «M» en el contexto del equipo sin un ejercicio completo de calibración cada vez que cambia el equipo. Es una forma barata de mantener las tallas coherentes a lo largo del tiempo.

Equivalencia entre tallas y story points

La equivalencia es opcional. Ayuda cuando tus herramientas de entrega (Jira, Azure DevOps, Linear) miden la velocidad en story points, pero la técnica no la necesita.

Una equivalencia habitual es XS=1, S=2, M=3, L=5, XL=8, que sigue la secuencia de Fibonacci usada en el planning poker. Algunos equipos usan XS=1, S=2, M=5, L=8, XL=13 para separar más los elementos grandes y forzar distinciones más claras cuando el backlog tiende al trabajo complejo.

Elijas la equivalencia que elijas, trátala como una convención del equipo y mantenla al menos un trimestre. Cambiarla a mitad de proyecto es como cambiar la unidad de medida a medio camino. Cualquier persona del equipo que equipare story points con tiempo debería leer el artículo de Scrum.org que desmonta mitos sobre los story points.

Imagina un equipo de producto que establece XS=1, S=2, M=3, L=5, XL=8 en Jira, mide la velocidad durante dos trimestres y nota que las historias XL se completan de forma mucho menos predecible que las M. Una respuesta sensata es una regla del equipo según la cual todo elemento XL se divide antes de entrar en un sprint. El dimensionamiento sirve entonces también como disparador para dividir historias.

Los equipos maduros que miden métricas de flujo como el cycle time y el throughput en lugar de la velocidad pueden usar las tallas como filtro aproximado de priorización sin convertirlas en puntos.

T-shirt sizing frente a planning poker frente a dot voting

La gente confunde estas tres técnicas, pero cumplen funciones distintas.

El t-shirt sizing es rápido y escala bien. Úsalo cuando tengas 20 o más elementos, poco tiempo o poco detalle a nivel de historia. El planning poker es más lento y más preciso: la escala de Fibonacci obliga a los participantes a elegir entre un 5 y un 8, lo que saca más matices que «M frente a L». El dot voting es un método de priorización. Ayuda a un grupo a ponerse de acuerdo sobre qué elementos abordar, y no dice nada sobre su tamaño.

Una regla que usan muchos agile coaches: t-shirt sizing para todo lo que esté por encima del nivel de sprint (épicas, features del roadmap, objetivos a nivel de programa) y planning poker para las historias de usuario que se refinan para el próximo sprint. El t-shirt sizing funciona como primera pasada gruesa, y la precisión del planning poker va donde compensa.

En las fases de discovery con clientes, esto suele significar que el t-shirt sizing cubre rápidamente conjuntos completos de features, y el planning poker toma el relevo para el refinamiento a nivel de historia cuando empieza el desarrollo. Las dos técnicas se complementan.

En cuanto a dónde encaja el dot voting: el dot voting te dice en qué trabajar, y el t-shirt sizing te dice cuánto mide el trabajo. Responden a preguntas distintas.

Fallos habituales

El sesgo de anclaje es el fallo más común. Quien habla primero arrastra al grupo. La revelación simultánea es lo que impide que la sesión se limite a confirmar la opinión del tech lead, así que no la trates como opcional.

El segundo es la inflación de tallas. Con el tiempo, los equipos amplían sin darse cuenta su definición de S hasta que algo que antes era una M pasa a llamarse S. Recalibrar cada mes o cada trimestre con las historias de referencia lo corrige. Sin eso, tus datos de velocidad se desvían de formas difíciles de diagnosticar.

Cuando los stakeholders tratan las tallas como compromisos, se trata de un problema de facilitación y de gestión de stakeholders. Las tallas son estimaciones aproximadas de orden de magnitud con una incertidumbre amplia. La forma de decirlo ayuda: «nuestra mejor estimación compartida de hoy» crea una expectativa distinta que «nuestra estimación».

El último fallo es el debate interminable. Los equipos intentan acordar una talla exacta para cada historia y convierten un ejercicio de 2 minutos en una discusión de 15 minutos. Si el equipo no se pone de acuerdo en 3-4 minutos, quédate con la talla mayor y marca la historia para desglosarla. Un timebox estricto de 3 minutos por elemento y una columna de «aparcado» en tu tablero de Miro para las historias en disputa pueden acortar considerablemente una sesión. El repaso de Scrum.org sobre errores habituales de estimación trata varios de estos patrones con más detalle.

T-shirt sizing en equipos remotos y distribuidos

Las sesiones remotas necesitan una estructura explícita de la que los equipos presenciales a veces pueden prescindir: un tablero digital compartido que todo el mundo vea, un protocolo de revelación estricto y una persona designada para controlar el tiempo. Sin eso, las sesiones remotas derivan en turnos secuenciales, en los que los participantes oyen las respuestas de los demás antes de comprometerse.

Los equipos distribuidos en distintas zonas horarias pueden dimensionar de forma asíncrona. Herramientas como Parabol permiten que cada miembro del equipo registre su estimación de forma independiente antes de una puesta en común síncrona que cubre solo los valores atípicos. Un patrón habitual en equipos de ingeniería distribuidos es el dimensionamiento asíncrono seguido de una breve sesión síncrona de unos 20 minutos para resolver los elementos en disputa, lo que requiere mucho menos tiempo de reunión que un planning poker totalmente síncrono.

La seguridad psicológica importa más en entornos remotos. Las personas de ingeniería junior y las nuevas en el equipo pueden sentirse expuestas cuando su estimación difiere de la de un colega sénior. Una revelación simultánea a ciegas protege las opiniones minoritarias que de otro modo podrían descartarse antes de que empiece la conversación.

Integrar el t-shirt sizing en el refinamiento del backlog

El t-shirt sizing encaja mejor en la fase de triaje y refinamiento grueso del refinamiento del backlog, donde se comprueba si los elementos están listos en lugar de planificarlos para un sprint concreto. Muchos equipos lo usan como control de preparación: los elementos XS, S y M pueden pasar a la sprint planning, mientras que los L y XL se marcan para dividirlos primero.

En entornos SAFe, el t-shirt sizing aparece a menudo en el refinamiento a nivel de programa para dimensionar las Features antes de desglosarlas en Stories. Los Product Managers pueden así prever la capacidad a lo largo de los incrementos de programa sin esperar un desglose completo a nivel de historia.

Registrar las tallas en tu herramienta del backlog te da un bucle de retroalimentación. Si tus elementos M suelen terminarse en 1-2 sprints, eso son datos de calibración. Si se desbordan con regularidad, hay que revisar la definición de M del equipo. Contrastar las historias de referencia con el historial de entregas es la forma en que los equipos mejoran, en lugar de repetir el mismo error de calibración cada trimestre.

Workshop Weaver incluye plantillas de facilitación para sesiones de t-shirt sizing, con la configuración de historias de referencia y la estructura de timebox descritas aquí, para que los equipos puedan seguir el proceso correctamente desde la primera sesión.

Reflexiones finales

La etiqueta de talla importa menos que la conversación que provoca. Cuando un equipo se divide entre XS y L en la misma historia, algo ha salido a la luz: la historia no está clara, la gente se imagina el trabajo de forma distinta o nadie sabe lo complejo que es. Esa conversación tiene que ocurrir antes de que empiece el desarrollo.

Si todavía no has facilitado una sesión de t-shirt sizing, pruébala en tu próximo refinamiento del backlog. Usa las cinco fases anteriores, prepara las historias de referencia de antemano, haz cumplir la revelación simultánea y limita los debates a tres minutos.

Después, lee sobre el planning poker para cuando necesites más detalle a nivel de historia, y sobre el dot voting como método rápido de priorización junto a la estimación. Entre las tres, estas técnicas cubren la mayor parte de lo que un equipo necesita para estimar y priorizar.