Una de las cosas que más quebraderos de cabeza suele darnos cuando hemos decidido adoptar SCRUM es cómo hacer estimaciones y cómo nos van a ayudar éstas a saber qué tal vamos y cuándo vamos a finalizar el proyecto. En SCRUM suele estimarse dos veces (sí, dos veces) pero no en la forma tradicional con una única y sesuda estimación en horas/días de trabajo al principio del proyecto.

Esta forma de estimar suele traer algo de polémica pero intentaré explicarlo lo mejor que pueda: Haremos una primera estimación grosso modo en puntos y no en horas en la que partiendo de la lista inicial de funcionalidades a desarrollar estimaremos el esfuerzo o dificultad que supondrá realizar cada una de los requisitos del proyecto. Este esfuerzo lo mediremos o, mejor dicho, lo calibraremos en puntos siguiendo por ejemplo la serie de Fibonacci (1, 2, 3, 5, 8, 13, …) o incluso usando las medidas usadas en las tallas de camiseta (S, M, L, XL, XXL, …)

Si atendemos al concepto de Cono de Incertidumbre, hagamos la estimación que hagamos, le dediquemos el tiempo y metodología que queramos, nuestra estimación será errónea (a menos que conozcamos cada uno de los detalles del proyecto). Rodrigo Corral lo explica muy bien en Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil (el resto del post no tiene desperdicio tampoco) Entonces ¿por qué dedicar tanto esfuerzo? Asignemos 1 o 2 puntos a las funcionalidades sencillas, 3 o 5 a las de dificultad media y 8 o 13 a las de dificultad alta o muy alta (¿necesitas más puntos? quizás deberías descomponer esta funcionalidad en otras más pequeñas)

Esto traerá un considerable ahorro de esfuerzo al estimar y, por qué no, también quitamos estrés al equipo, que tendrá miedo a equivocarse. Con la estimación a alto nivel mediante puntos evitamos algunos de los inconvenientes de las estimaciones en horas: Si indicamos que en una tarea vamos a tardar 40 horas, la regla de que el trabajo se expandirá hasta tomar todo el tiempo disponible se aplicará a esto también. Por otra lado se evitará un fallo común en los que comienzan con SCRUM (sí, yo también lo cometí) y que consiste en pensar que «Si se ha trabajado 40 horas en esta tarea, el burndown graphic deberá bajar en 40 horas» Esto daría una falsa sensación de avance en el proyecto si la tarea no está completamente terminada y aprobada por el cliente.

La segunda estimación la haremos cuando planifiquemos las tareas del sprint. En esta planificación tendremos un mayor conocimiento del proyecto y de lo que implica cada tarea. Podríamos hacer entonces una planificación en horas aunque hay equipos que aún en ese momento usan una estimación en puntos o deciden no estimar en absoluto (ver entrada sobre técnicas de estimación en ScrumAlliance.org)

Estas estimaciones nos permitirán conocer el ROI (retorno de inversión) de cada funcionalidad para que el cliente pueda decidir qué tareas quiere realizar en el siguiente sprint y nos permitirá también, después de algunos sprints, conocer con bastante exactitud cuál es la velocidad del equipo (de nuevo, tema para otro post)

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría