Puntos de historia: ¿Por qué son mejores que las horas?

Los puntos de historia proporcionan estimaciones más precisas, reducen drásticamente el tiempo de planificación, predicen con mayor exactitud las fechas de lanzamiento y ayudan a los equipos a mejorar el rendimiento. Las horas dan peores estimaciones, introducen grandes cantidades de residuos en el sistema, dificultan la planificación de lanzamientos del Product Owner y confunden al equipo sobre qué mejoras del proceso han funcionado realmente.

 

Se ha publicado un nuevo e interesante estudio. The Standish Group ha actualizado sus conclusiones sobre las tasas de éxito de los proyectos basándose en el análisis de la última década de datos con decenas de miles de puntos de datos. Además, Microsoft ha publicado nuevos resultados de investigación que demuestran que la estimación ágil es asombrosamente más precisa que la estimación tradicional de proyectos. Véase:

Scrum + Prácticas de ingeniería: Experiencias de tres equipos de Microsoft
Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan
Ganador del premio IEEE al mejor artículo del sector

A muchas personas que han gestionado proyectos con horas les cuesta entender por qué los puntos de historia son mejores. No han entendido algunos datos fundamentales publicados desde hace más de 60 años en la literatura del sector, así como las investigaciones más recientes.

En primer lugar, veamos los últimos datos sobre fracasos de proyectos. Los índices de fracaso están aumentando en los proyectos de TI durante la actual perturbación del sistema financiero mundial. El último análisis del grupo Standish muestra que los proyectos ágiles tienen una tasa de éxito tres veces superior a la de los proyectos tradicionales. Jim Johnson recomienda ahora el uso universal de la práctica ágil en todos los proyectos.

De hecho, el último estudio de Forrester Group muestra que:
Las métricas comunes de gestión de proyectos condenan al fracaso a los departamentos de TI

Los inversores de capital riesgo con los que trabajo dicen que nunca han visto un diagrama de GANTT correcto en una reunión del consejo de administración. Cuando profundizan en el problema, dicen que ninguno de sus equipos directivos conocía la velocidad de sus equipos antes de implantar Scrum. El desconocimiento de la velocidad de producción de los equipos es la causa fundamental de que 100% los planes de lanzamiento no sean precisos en sus reuniones de consejo.

La estabilidad de una historia de usuario es fundamental para la planificación. Una historia de tres puntos hoy es de tres puntos el año que viene y es una parte medible del lanzamiento del producto para un Product Owner. Las horas necesarias para realizar una historia dependen de quién la realice y del día en que lo haga. Esto cambia cada día. El diagrama de GANTT supone un número fijo de horas para una persona ficticia (que a menudo no es la persona encargada de la ejecución) y asume dependencias fijas (que siempre cambian). Un estudio de 80 proyectos multimillonarios en GSI Commerce (ahora propiedad de eBay) demostró que los mejores expertos de la empresa eran totalmente incapaces de estimar cuánto tiempo llevaría un proyecto a las personas que realmente lo ejecutaban.

Se podría pensar que estos datos harían que la gente cambiara su comportamiento, pero muchas empresas parecen preferir seguir fracasando y ser adquiridas o quebrar antes que mejorar sus técnicas de gestión de proyectos.

La investigación de la Rand Corporation en los años 40 demostró claramente que los humanos no son buenos estimando horas y la experiencia práctica confirma repetidamente la investigación. Los investigadores recomendaron el método Delphi para la estimación, que se adoptó en el desarrollo de software como el método más eficaz. Banda ancha Delphi técnica. La misma técnica está ahora integrada en la práctica denominada Planning Poker para equipos ágiles.

La métrica de gestión para la entrega de proyectos debe ser una unidad de producción. La producción es la condición previa para los ingresos y las empresas dicen que están en el negocio para aumentar los ingresos y los márgenes (aunque en la planificación de proyectos a menudo hacen lo contrario). Al menos un grupo de capital riesgo tiene claro que lo importante es el dinero y que el dinero procede de la velocidad de producción combinada con la calidad del producto. Las horas son un gasto y deben reducirse o eliminarse siempre que sea posible.

Los mejores datos sobre el rendimiento individual de los desarrolladores proceden de la Universidad de Yale y ya se han publicado anteriormente en este blog. El mejor desarrollador de un proyecto tarda una hora en completar una tarea, mientras que el peor tarda 10 horas (dentro de un proyecto) o 25 horas (entre proyectos). En el caso de los equipos, la diferencia es un orden de magnitud mayor. Los datos publicados por Larry Putnam muestran que una hora para el equipo más productivo se convierte en 2000 horas para el equipo menos productivo.

Las horas completadas no dicen nada al Product Owner sobre cuántas prestaciones puede enviar y cuándo puede hacerlo.

La métrica importante es el número de puntos de historia que el equipo puede entregar por unidad de tiempo de calendario. Los puntos por sprint son la velocidad. Por lo tanto, estimamos todo en puntos para el Product Owner para que pueda crear una hoja de ruta basada en la velocidad del equipo y ajustar el plan si la velocidad cambia.

La forma en que hacemos la estimación por puntos de historia da mejores estimaciones que las estimaciones por hora, ya que son más precisas y tienen menos variación. Una empresa CMMI Nivel 5 determinó que la estimación de story points reduce el tiempo de estimación en 80% permitiendo a los equipos hacer más estimación y seguimiento que un equipo típico de cascada. Una empresa de telecomunicaciones se dio cuenta de que la estimación de puntos de historia con póquer de planificación era 48 veces más rápida que las prácticas de estimación en cascada en la empresa y daba tan buenas o mejores estimaciones.

Los puntos de historia son, por tanto, más rápidos, mejores y más baratos que las horas, y los equipos de mayor rendimiento abandonan por completo cualquier estimación horaria, ya que la consideran un despilfarro que sólo les ralentiza.

Para un análisis completo del debate sobre los puntos frente a las horas, véase el artículo de Scrum Inc. seminario web sobre el tema.