Story points vs Horas
Source: Dev.to
Estimación de tareas en desarrollo de software
El problema de estimar en horas
“Sin duda, a todos nos han pedido o pedirán estimar una tarea en algún momento. Naturalmente, el siguiente pensamiento que nos llega a la cabeza es estimar horas – al fin y al cabo, todos sabemos cuánto tarda algo, es una medida que usamos todos los humanos en el día a día.”
En desarrollo de software, estimar en horas puede generar:
- Presión personal: al promediar estimaciones de distintos miembros del equipo, el tiempo “promedio” puede quedar por debajo de lo que realmente necesitamos.
- Desconfianza: si no terminamos en el tiempo promedio, sentimos que no somos lo suficientemente buenos y tememos que se interprete como un problema de rendimiento.
Story points: ¿qué son y por qué ayudan?
- No miden tiempo, sino esfuerzo relativo y complejidad (y, como veremos, incertidumbre).
- Cuando decimos que una tarea tiene 5 puntos, nos referimos a que es cinco veces más compleja que una de 1 punto.
- Al ser relativos, la estimación es menos dependiente de quién la va a hacer, lo que facilita llegar a un consenso.
Consenso con story points
Supongamos que yo estimo 3 puntos y María estima 2 puntos. En lugar de promediar o elegir arbitrariamente, podemos:
- Discutir la incertidumbre de la tarea.
- Si aún hay dudas, subir a 3 puntos; si la incertidumbre parece menor, quedarnos en 2 puntos.
- Recordar que siempre podemos refinar la estimación más adelante (ver sección Re‑estimación).
Representación de esfuerzo e incertidumbre
| Escala | Descripción |
|---|---|
| Tallas de camiseta | XS, S, M, L, XL, XXL – menos preciso, fácil de calibrar. Ideal cuando el equipo es nuevo o hay poca información. |
| Poder de 2 | 1, 2, 4, 8, 16 – cada valor dobla al anterior, reflejando mayor incertidumbre. |
| Secuencia de Fibonacci | 1, 2, 3, 5, 8, 13 – al crecer, indica incremento de incertidumbre. |
| Escala lineal corta | 1‑5 o 1‑10 – tentadora cuando la incertidumbre parece baja, pero puede generar debates sobre valores intermedios (p. ej., 6 vs 7). |
Estrategias de estimación que conozco
- Tallas de camiseta (XS‑XXL).
- Poder de 2 (1, 2, 4, 8, 16).
- Fibonacci (1, 2, 3, 5, 8, 13).
- Escala lineal (1‑5 o 1‑10).
Cada una tiene sus ventajas y desventajas; la elección depende del nivel de información del dominio y de la madurez del equipo.
Sprint de calibración (Sprint 0)
- Objetivo: validar la escala elegida con tareas reales de nivel 1.
- Proceso: el equipo toma algunas tareas pequeñas, las completa y compara el esfuerzo real con la estimación inicial.
- Resultado: se ajustan las estimaciones del resto del backlog con base en la experiencia obtenida.
Re‑estimación de tareas
| Momento | Qué hacer |
|---|---|
| Antes del planning | Durante los primeros 15 min de la ceremonia, refinar las tareas que entrarán en el próximo sprint (no es necesario una reunión ad‑hoc). |
| Tareas próximas al sprint | Re‑estimar si el equipo percibe que están muy desajustadas respecto a la nueva referencia. |
| Tareas lejanas en el backlog | No es necesario re‑estimar ahora; pueden cambiar de alcance antes de ser trabajadas. |
Velocidad del equipo
- Velocidad = puntos promedio completados por sprint.
- Ejemplo: si la velocidad es 30 puntos/sprint, podemos proyectar cuántos sprints requerirá una funcionalidad grande sumando sus story points.
Story points y productividad individual
- No usar los story points terminados por sprint como métrica de productividad personal.
- Razones:
- Las tareas varían en complejidad y contexto.
- Los puntos son una estimación del equipo, no una medida de desempeño individual.
En la empresa del ejemplo, comparar que María terminó 20 puntos y Juan 10 puntos llevó a conclusiones erróneas sobre su rendimiento.
Conclusión
- Story points permiten estimar de forma relativa, reduciendo la presión de cumplir con una cifra de horas predefinida.
- Llegar a un consenso sobre la incertidumbre y la complejidad es clave.
- Un sprint de calibración y la re‑estimación continua mantienen la precisión del backlog.
- La velocidad del equipo es la métrica útil para planificación, no la productividad individual basada en puntos.
Este documento resume las ideas principales sobre estimación con story points y buenas prácticas para equipos ágiles.
Estimación con Story Points
“o del individuo.”
Aunque no me siento orgulloso de ello, recuerdo que en su momento algunos de los desarrolladores (yo incluido) empezamos a inflar las estimaciones para protegernos. Es ahí donde la herramienta de estimación con story points pierde utilidad.
Estimar es adivinar. No es una ciencia exacta. No obstante, la idea es hacerlo lo mejor posible para que el negocio pueda hacer promesas de entrega del producto.
Preguntas para reflexionar
- Si has llegado hasta aquí, ¿qué piensas sobre lo que dije?
- ¿Has usado story points?
- ¿O prefieres otro sistema de estimación?
- ¿Por qué?