3. Unidades de medida en la estimación ágil

Las unidades de medida en estimación ágil funcionan como un lenguaje común que ayuda a comparar historias y prever la capacidad del equipo. Dependiendo de su madurez, el contexto del producto y la cultura de la organización, los equipos combinan distintos enfoques para expresar esfuerzo, complejidad o duración.

Seleccionar la unidad adecuada implica equilibrar precisión, facilidad de adopción y la posibilidad de ser convertida en decisiones reales. A continuación se describen las unidades más utilizadas y cómo relacionarlas con la velocidad del equipo y con los conceptos de esfuerzo y complejidad.

3.1. Story Points

Los Story Points son números enteros que representan el esfuerzo relativo de una historia de usuario. No indican horas, sino una combinación de factores como complejidad técnica, trabajo manual, riesgos y volumen de funcionalidad. La clave es compararlos contra historias de referencia para mantener la coherencia.

Buenas prácticas para utilizarlos:

• Definir una historia ancla: elegir una historia reciente, conocida por todos, y asignarle un valor base (por ejemplo, 3 puntos). Cada nueva historia se compara con esa ancla.
• Calibrar con experiencia real: después de cada sprint, contrastar los puntos comprometidos con los entregados y ajustar la escala si aparecen desviaciones constantes.
• Integrar múltiples dimensiones: cuando haya dudas, analizar cómo afectan la simplicidad del código, la necesidad de pruebas y la dependencia de otros equipos.

La ventaja principal de los Story Points es que desacoplan la estimación del tiempo y promueven conversaciones sobre riesgos y valor antes de avanzar a la planificación detallada.

3.2. T-shirt sizes (XS, S, M, L, XL)

Los tamaños de camiseta son una metáfora visual para clasificar historias en categorías de esfuerzo. Se utilizan cuando el equipo necesita ordenar rápidamente un backlog grande o cuando la precisión no es tan relevante como la velocidad para estimar. Son útiles en etapas tempranas de un producto o durante sesiones de refinamiento masivo.

Tamaño	Descripción típica	Uso recomendado
XS	Historias pequeñas, con cambios mínimos o correcciones simples.	Puede entrar como trabajo no planificado sin afectar la capacidad.
S	Implementaciones conocidas y con bajo riesgo técnico.	Se pueden agrupar varias en un mismo sprint.
M	Funcionalidades con más de un escenario o integración.	Requieren refinamiento adicional antes de comprometerse.
L	Trabajos que demandan coordinación entre varias personas o equipos.	Evaluar si conviene dividirla en historias más pequeñas.
XL	Epics disfrazados de historias.	Necesitan descomposición antes de entrar al flujo de desarrollo.

Una vez ordenado el backlog con tamaños de camiseta, muchos equipos convierten la clasificación a Story Points o a otra escala numérica para facilitar la medición de la velocidad.

3.3. Ideal Days y su relación con la velocidad

Los Ideal Days representan la cantidad de días que una persona necesitaría para completar una historia si pudiera dedicarle atención exclusiva y sin interrupciones. Aunque se parecen a las horas o días reales, siguen siendo una medida relativa, porque eliminan reuniones, tareas administrativas y multitarea.

Su principal utilidad radica en construir escenarios rápidos: si un equipo de cinco personas estima que una historia lleva 2 Ideal Days y el sprint dura 10 días, podría proyectarse que la historia consume aproximadamente el 40% de la capacidad del equipo. Para convertir Ideal Days en velocidad:

1. Sumar los Ideal Days de todas las historias completadas durante un sprint.
2. Dividirlo por la cantidad de miembros disponibles para obtener la capacidad promedio individual.
3. Usar ese valor como referencia para planificaciones futuras, ajustándolo con la evidencia real de interrupciones.

Aunque los Ideal Days facilitan conversar con stakeholders acostumbrados a planes tradicionales, hay que evitar confundirlos con días calendario reales. Siempre se recomienda validar las proyecciones con la velocidad histórica.

3.4. Puntos de esfuerzo vs. puntos de complejidad

Al estimar es importante distinguir si se evalúa el esfuerzo total requerido o la complejidad inherente a la tarea. Los puntos de esfuerzo incluyen todo el trabajo necesario (diseño, desarrollo, pruebas, coordinación), mientras que los puntos de complejidad se centran en la dificultad técnica o en la cantidad de incógnitas.

Ambas perspectivas son útiles, pero deben ser consistentes dentro del equipo para evitar ambigüedades. La siguiente tabla muestra cómo combinarlas:

Enfoque	Qué considera	Cuándo usarlo
Puntos de esfuerzo	Tiempo relativo, coordinación, pruebas, despliegues y soporte.	Planificar capacidad de sprint y evaluar carga de trabajo total.
Puntos de complejidad	Dificultad técnica, algoritmos, dependencias externas.	Identificar historias que requieren investigación o expertos especializados.
Enfoque combinado	Ambas dimensiones en una sola cifra (por ejemplo, Story Points).	Refinar backlog manteniendo una escala sencilla de comunicar.

Sea cual sea la unidad elegida, lo esencial es revisarla periódicamente y asegurarse de que todos interpretan los números del mismo modo. La coherencia en la medida permite transformar las estimaciones en decisiones sobre alcance, plazos y riesgos.