En este artículo vamos a desgranar el por qué profesionales de la talla de Mike Cohn o Jeff Sutherland recomiendan el uso de Puntos de historia para estimar.
La estimación con puntos de historia supone uno de los cambios de mentalidad más difíciles de entender y sobre todo de aplicar en el marco de la implantación de Scrum en tu empresa.
Pero primero y a modo de contexto …
¿Cómo se estima de forma tradicional?
Tradicionalmente se ha venido estimando las tareas en horas hombre, lo que significa “medir” una tarea en base al tiempo que se tarda en resolverla.
El proceso de estimación es de base muy complicado. Requiere un análisis a priori de la complejidad de la tarea para así, determinar cuánto tiempo se tardaría idealmente en ejecutarla. Adicionalmente se tiene que las estimaciones, en el sistema tradicional o cascada, se suelen hacer en un estadio temprano del proyecto, donde apenas tenemos información acerca de la complejidad de las tareas a realizar, ni somos conscientes de muchos de los riesgos que pueden influir el en desarrollo de éstas.
Resumiendo, traducimos la complejidad y el esfuerzo de las tareas en tiempo ideal de ejecución. Dicho de otro modo; en un estadio temprano de un proyecto, donde muchas veces el cliente no tiene muy claro sus requerimientos, mediante un análisis complejo, suponiendo indicadores intrínsecos (desempeño, mismo nivel de entendimiento de la complejidad) de un equipo de desarrollo que aún no está definido y traduciendo todo esto en horas hombre: ¿Qué puede salir mal?
Puntos débiles
Esta forma de estimar tiene varios puntos débiles:
- La estimación no la realiza el equipo que la va a construir. Por lo que la complejidad que a priori se estimó, puede no ser entendida en la misma magnitud por el equipo de desarrollo que la va a ejecutar. Además, que el equipo no participe en la estimación no genera inclusión ni compromiso con la misma.
- Se hace en un estadio inicial, sin conocer previamente cómo se desenvuelve el equipo al resolver tareas similares del mismo proyecto. Tampoco se conoce en profundidad el negocio, ni todo el detalle de las tareas. Esto hace la estimación poco precisa.
- Es necesario reestimar y replanificar varias veces las tareas durante la ejecución del proyecto.
- Las estimaciones se desvían en muchos casos por un gran margen, produciendo una muy baja predictibilidad.
- No se adapta a entornos de requerimientos poco definidos o cambiantes.
Como se puede ver no son pocas las desventajas de utilizar este tipo de estimación tradicional. A estas alturas te estarás preguntando, si tiene tantas desventajas, ¿por qué hay tanta resistencia al cambio?
En parte se debe a que se ha venido utilizando desde los inicios del desarrollo del software, con el Proceso Unificado de Desarrollo (UDP en sus siglas en inglés). Todo el mundo está habituado al mismo y tiene claros y en muchos casos asumidos, los riesgos y problemas que entraña. Pero por otro lado se debe al miedo que tenemos los humanos al cambio, es más cómodo permanecer en nuestra zona de confort, donde ya “sabemos” lo que puede ocurrir y “controlamos” el devenir de los proyectos. Esto no es más que una ilusión que nos impide ver el bosque y nos limita nuestra adaptación al cambio, citando a Goethe “Nadie es más esclavo que quien falsamente cree ser libre.”
Hemos visto qué falla del sistema actual de estimación, pero ¿qué son los puntos de historia?, ¿por qué debería utilizarlos para estimar, que me aportan?
¿Por qué estimar en puntos de historia? ¿Qué ventajas reporta?
Pero, ¿Qué son los puntos de historia? Los puntos de historia son un artefacto abstracto que nos permite ponernos de acuerdo más fácilmente en la complejidad, esfuerzo y riesgo que tiene una determinada tarea. Si quieres saber más acerca de los puntos de historia puedes consultar este artículo: ¿que son los puntos de historia?
Al abstraernos de los aspectos particulares de cada individuo es más sencillo llegar a un acuerdo con respecto al “tamaño” de las Historias de Usuario o de las tareas. Ésto nos ayuda a que las estimaciones sean más ágiles y sencillas.
Pero, ¿cuánto más ágiles y sencillas son las estimaciones? Para averiguarlo, Jeff Sutherland realizó un estudio analizando su uso en 5 compañías. La conclusión que arrojó el estudio es que utilizando Puntos Historia se reduce el tiempo que se dedica a estimar en un 80%. Para tener más detalle sobre este estudio se puede revisar este interesante artículo donde de abunda en el estudio.
En resumen, estimar en puntos de historia hace mucho más eficientes nuestras sesiones de refinamiento y ceremonias de Sprint Planning.
Si estimamos en puntos de historia es mucho más fácil entender y utilizar varios indicadores (KPIs) como son la velocidad o la capacidad de los equipos que están íntimamente ligados entre sí:
- La velocidad de un equipo es a grandes rasgos la suma de los puntos de historia que son terminados (quemados) en un Sprint.
- La capacidad es la cantidad de trabajo que puede asumir un equipo en un Sprint y se apoya en la velocidad que tiene un equipo.
En resumen
Utilizando los puntos de historia como referencia para estimar, simplificamos la tarea de estimación, ya de por sí compleja y poco fiable en comparación con las tradicionales.
Esto nos permite ser más ágiles en nuestras ceremonias Agiley nos ayuda a entender y utilizar el uso de indicadores como la velocidad o la capacidad de los equipos.
