Puntos de Historia en desarrollo — qué son, escalas de evaluación y aplicación
Los puntos de historia son unidades relativas para medir la complejidad de las tareas en metodologías ágiles de desarrollo. A diferencia de las horas, los puntos de historia consideran no solo el tiempo, sino también la complejidad, los riesgos y la incertidumbre de una tarea. Según Scrum.org, 2023, los equipos que utilizan estimación relativa en puntos de historia incumplen los plazos de sprint un 25% menos que los equipos que estiman en horas.
Puntos Clave
- Puntos de historia — unidades relativas de complejidad de la tarea, no vinculadas al tiempo.
- Escalas principales — Fibonacci (1, 2, 3, 5, 8, 13, 21) y lineal (1, 2, 3, 4, 5).
- Velocity — la cantidad de puntos de historia que un equipo completa por sprint, utilizado para pronosticar.
- Principal ventaja — los puntos de historia no dependen del desarrollador específico y reflejan la complejidad para el equipo.
- Regla clave — una tarea de referencia define la escala: el equipo acuerda qué significa 1 punto de historia.
¿Qué son los puntos de historia?
Los puntos de historia son una métrica de complejidad de tareas utilizada en Scrum y otras metodologías ágiles. El equipo evalúa cada tarea no en horas, sino en unidades relativas: “esta tarea es el doble de compleja que la referencia.” Este enfoque nivela la diferencia de velocidad entre diferentes desarrolladores y se centra en la complejidad.
Origen del término
El concepto de puntos de historia surgió a principios de la década de 2000 con la popularización de Scrum. Uno de los primeros en describir el método fue Ron Jeffries como parte de Extreme Programming (XP). La idea era alejarse de la estimación en “horas hombre,” que siempre es inexacta, hacia una complejidad relativa que el equipo determina colectivamente. Hoy, los puntos de historia son el estándar de la industria para equipos ágiles.
Factores considerados en los puntos de historia
Al estimar en puntos de historia, el equipo considera tres factores: volumen de trabajo (cantidad de código, pantallas, lógica), complejidad (desafíos técnicos, nuevas tecnologías) e incertidumbre (requisitos poco claros, riesgos). Un punto de historia puede significar “una tarea simple sin riesgos,” mientras que 8 puede significar “una tarea compleja con alta incertidumbre.”
Escalas de puntos de historia: cómo elegir
La elección de la escala de puntos de historia afecta la precisión de la estimación y la conveniencia de la planificación. La escala más popular es la secuencia de Fibonacci, pero hay alternativas.
| Escala | Valores | Ventajas | Desventajas |
|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Aumento natural de la dispersión en tareas grandes | Difícil para equipos nuevos |
| Lineal | 1, 2, 3, 4, 5 | Simple y comprensible | Sin dispersión para tareas grandes |
| Potencia | 1, 2, 4, 8, 16, 32 | Máxima dispersión para tareas grandes | Las tareas grandes son difíciles de distinguir |
| Talla de camiseta | S, M, L, XL | Estimación rápida y aproximada | Inexacta, requiere conversión |
¿Por qué Fibonacci? La psicología de la escala
La secuencia de Fibonacci no fue elegida al azar. La diferencia entre 1 y 2 es mínima (50%), mientras que entre 13 y 21 es significativa (62%). Esto refleja la realidad: las tareas pequeñas se estiman con mayor precisión, las tareas grandes con mayor dispersión. Cuando una tarea se estima en 21 puntos de historia, el equipo entiende: “no sabemos cuánto tiempo tomará, pero definitivamente es más de 13.” La escala de Fibonacci evita la falsa precisión.
La tarea de referencia — base de la escala
Para que la escala funcione, el equipo acuerda una referencia: “la tarea X es 1 punto de historia.” Generalmente se elige una tarea simple y bien conocida como referencia: “añadir un campo de texto a una pantalla” o “corregir un error tipográfico.” Todas las demás tareas se estiman en relación con la referencia. Sin una referencia, los puntos de historia pierden su significado — cada persona entiende la unidad de manera diferente.
Velocity del equipo y pronóstico
Velocity es el número promedio de puntos de historia que un equipo completa por sprint. Esta es una métrica clave para pronosticar los plazos del proyecto.
Cómo se calcula el velocity
Velocity se calcula en base a las tareas completadas: se suman los puntos de historia de todas las tareas que el equipo logró finalizar (se cumple la definición de completado). Las tareas no finalizadas no se cuentan. Para mayor precisión, se toma el promedio de los últimos 3–5 sprints. Por ejemplo, si un equipo completó 20, 22, 18 y 24 puntos de historia en los últimos 4 sprints, velocity = 21 ph.
Pronóstico mediante velocity
Conociendo el velocity y el volumen total del backlog en puntos de historia, se puede pronosticar el número de sprints hasta el lanzamiento. Por ejemplo, si el backlog tiene 210 puntos de historia y el velocity = 21, se necesitarán 10 sprints. Este es un pronóstico aproximado que se refina a medida que avanza el trabajo. Importante: el velocity es un promedio, no un compromiso. Planifique basándose en el límite inferior (18 ph), no en el promedio.
Cómo aumentar el velocity
Velocity no se puede aumentar por decreto — es un síntoma de la salud de los procesos. El crecimiento sostenible del velocity se logra mediante: reducción de la deuda técnica, mejora de los procesos de revisión de código, reducción de cambios de contexto, automatización de pruebas y CI/CD. Importante: el velocity de diferentes equipos no se puede comparar — cada equipo define los puntos de historia a su manera.
Puntos de historia vs horas: qué y cuándo usar
Los puntos de historia y las horas tienen diferentes propósitos, y la elección entre ellos depende del contexto. Los equipos experimentados utilizan ambos enfoques para diferentes tareas.
Cuándo funcionan mejor los puntos de historia
Los puntos de historia son indispensables para la planificación de sprints: no dependen de quién realizará la tarea. Un junior puede hacer 2 ph por día, un senior 4 ph, pero la estimación de la tarea sigue siendo 2 ph para ambos. Los puntos de historia permiten rastrear la productividad del equipo sin comparar desarrolladores. Esto reduce la presión política y mejora el ambiente del equipo.
Cuándo son necesarias las horas
Las horas son necesarias para compromisos externos: contratos, presupuestos, informes para el cliente. El cliente quiere saber no “8 puntos de historia” sino “3 semanas.” Para convertir puntos de historia a horas, se utiliza la tasa de conversión histórica: el equipo sabe que 1 ph equivale aproximadamente a 4 horas de trabajo. La conversión debe ser transparente y basada en datos, no en suposiciones.
Enfoque combinado
Muchos equipos utilizan un enfoque combinado: las tareas se estiman en puntos de historia para la planificación del sprint, y luego el gerente las convierte a horas/días para los informes externos. Es importante no mezclar los dos sistemas en un mismo proceso: o se estima en puntos de historia y se deriva el tiempo del velocity, o se estima directamente en horas.
Errores comunes al trabajar con puntos de historia
La implementación de puntos de historia a menudo va acompañada de errores que anulan los beneficios de la estimación relativa. Estos son los más comunes.
Vincular los puntos de historia al tiempo
El error más común — el equipo acuerda: “1 ph = 4 horas.” En este caso, los puntos de historia pierden su significado y se convierten en horas con otro nombre. Los puntos de historia deben ser relativos, no vinculados al tiempo. Si la tarea A es el doble de compleja que la tarea B, recibe 2 ph, independientemente de cuántas horas lleve.
Estimación post-factum
Cuando una tarea se estima después de completarse — esto no es estimación, es una constatación. Los puntos de historia deben asignarse antes de comenzar el trabajo, en el momento de máxima incertidumbre. La estimación post-factum distorsiona el velocity y no aporta beneficios para la planificación. Además, crea una falsa sensación de precisión.
Comparar el velocity entre equipos
Comparar el velocity del equipo A y del equipo B es un ejercicio sin sentido. Cada equipo define la referencia y la escala de manera diferente. Para un equipo, 1 ph es una tarea simple de una hora, para otro es una tarea de un día. Solo se puede comparar el velocity de un mismo equipo a lo largo del tiempo: si está creciendo o disminuyendo.
Escala inconsistente
Cuando tareas diferentes con la misma complejidad reciben diferentes puntos de historia, y las más complejas reciben menos, la escala se rompe. El equipo debe calibrar la escala regularmente: cada 3–6 sprints, revisar retrospectivamente qué tan bien las estimaciones coincidieron con la complejidad real. Esto mejora la consistencia de las estimaciones.
Preguntas Frecuentes
¿Cuántas horas hay en un punto de historia?
Los puntos de historia no tienen un equivalente fijo en horas. Es una unidad relativa: 1 ph = complejidad de la tarea de referencia. Para la conversión a horas, utiliza la tasa de conversión histórica de tu equipo: divide el número promedio de horas trabajadas por sprint entre el velocity. Generalmente, 1 ph = 4–8 horas, pero esto varía para cada equipo.
¿Se pueden usar puntos de historia en Kanban?
Sí, los puntos de historia se pueden usar en Kanban, pero con ciertas salvedades. Kanban no tiene sprints fijos, por lo que el velocity se calcula por semana o mes en su lugar. Los equipos Kanban a menudo usan el Cycle Time en lugar de puntos de historia — el tiempo que una tarea toma desde el inicio hasta el final. La elección depende de las características del equipo.
¿Qué hacer si el equipo no puede ponerse de acuerdo en una estimación?
Si las estimaciones divergen (uno da 3 ph, otro da 13), es una señal de que la tarea no se comprende bien. Descomponga la tarea en partes más pequeñas. Discuta los riesgos e incertidumbres que ven los diferentes desarrolladores. Si la tarea es grande, estímela como un Spike (investigación de 2–4 días) en lugar de puntos de historia.
¿Cómo dejar de estimar en horas y pasar a puntos de historia?
La transición toma de 3 a 6 sprints. Comience eligiendo una escala (Fibonacci es la opción más segura) y definiendo una tarea de referencia. Realice 2–3 sesiones de Planning Poker. Calcule el velocity después de cada sprint. No convierta los puntos de historia a horas — deje que el equipo se acostumbre al nuevo sistema. Después de 3 sprints, verá cuánto ha mejorado la planificación.
¿Cambia la estimación en puntos de historia de una tarea después de completarla?
No, la estimación no cambia. Los puntos de historia son una estimación preliminar de complejidad realizada antes de comenzar el trabajo. Después de completar la tarea, la estimación sigue siendo la misma, incluso si el esfuerzo real fue diferente. Cambiar la estimación post-factum distorsiona las estadísticas y anula el propósito del pronóstico. Analice las discrepancias durante las retrospectivas, pero no cambie las estimaciones retroactivamente.
Resumen
- Puntos de historia — unidades relativas de complejidad, no vinculadas al tiempo, la base de la estimación ágil.
- Escalas principales — Fibonacci (recomendada), lineal, potencia, talla de camiseta.
- Velocity — número de puntos de historia por sprint; métrica clave para pronosticar plazos.
- Puntos de historia vs horas — puntos de historia para planificación de sprints, horas para compromisos externos.
- Errores comunes — vincular al tiempo, estimación post-factum, comparar equipos, escala inconsistente.
- Tarea de referencia — base de la escala; sin ella, los puntos de historia pierden su significado.
- Ventaja clave — los puntos de historia no dependen del individuo y permiten centrarse en la productividad del equipo.
Desarrollaremos una aplicación móvil llave en mano
IT Sectr crea aplicaciones para iOS y Android para startups y empresas desde 2017. Le asesoraremos y le propondremos la mejor solución.
Lea también