¿Deberías Estimar en Horas o Puntos de Historia?
En casi todos los equipos ágiles con los que he estado trabajando durante los últimos 15 años surgió la pregunta: ¿Debemos estimar el trabajo en horas o puntos de historia?
Aquí veremos los pros y los contras y concluiremos que, si bien existen pocas ventajas de los puntos de historia sobre las estimaciones en horas, existen muchas ventajas de las estimaciones en horas sobre los puntos de historia y que, por lo tanto, casi siempre debemos usar estimaciones en horas.
1. ¿Qué Son los Puntos de Historia?
Los puntos de historia son una unidad de medida para expresar una estimación del esfuerzo total que se requerirá para implementar completamente una característica de un producto o cualquier otra pieza de trabajo.
Cuando estimamos con puntos de historia, asignamos un valor en puntos a cada tarea. Los valores más comunes para los puntos de historia son:
● 0.5: tarea diminuta
● 1: tarea muy pequeña
● 2: tarea pequeña
● 3: más que una tarea pequeña
● 5: tarea normal
● 8: tarea algo grande
● 13: tarea grande
● 20: tarea muy grande
● 40: tarea extremadamente grande
● 100 : tarea enorme
Es importante tener en cuenta que los puntos no miden qué tan compleja o difícil es una tarea, sino sólo cuánto esfuerzo en términos de tiempo requiere. Por ejemplo, tanto una cirugía cerebral como colocar 5000 estampillas en cartas pueden llevar 3 horas. Si bien es cierto que una cirugía cerebral es mucho más difícil que poner estampillas en una carta, esto no afecta los puntos de historia. Ambas tareas tendrían los mismos puntos de historia. Eso muestra que los puntos de historia realmente son una medida de tiempo, al igual que los días, las horas y los minutos.
No obstante, muchos equipos ágiles prefieren estimar en puntos de historia en lugar de estimar en horas. Las razones de esto las discutiremos a continuación.
2. Ventajas de Estimar en Puntos de Historia Sobre Estimar en Horas
Aquí mostraremos las ventajas de estimar en puntos de historia sobre estimar en horas.
Estas son las principales ventajas de los puntos de historia:
● Estandarizan diferentes miembros del equipo
● Son ágiles
● Permiten la planificación póquer
● Son más fiables
● Permiten una estimación más rápida
● Limitan la presión de tiempo de la gerencia
2.1. Los puntos de historia estandarizan a los diferentes miembros del equipo
El argumento principal para el uso de puntos de historia sobre estimaciones en horas es que no dependen de las habilidades y la velocidad de los desarrolladores de software; los puntos de historia son los mismos sin importar si un desarrollador junior o un desarrollador senior está trabajando en una tarea. Por ejemplo, una funcionalidad puede llevarle a un desarrollador junior 6 horas, mientras que al desarrollador senior le toma 2 horas. Entonces, si tuviéramos que hacer estimaciones por hora, primero tendríamos que saber quién será responsable de la tarea. Sin embargo, para los puntos de historia, podríamos asignar 3 puntos de historia a esa característica, sabiendo que el tiempo esperado variaría dependiendo de quién la esté desarrollando.
2.2. Los puntos de historia son ágiles
Algunos defensores de los puntos de historia dicen que son mejores porque son ágiles. Pero, ¿qué tienen de ágil? Solo que los puntos de historia están siendo utilizados por muchos equipos ágiles. Pero podríamos implementar una metodología ágil, sin medir el trabajo en puntos de historia sino en horas. De hecho, como veremos a continuación, las estimaciones en horas respaldan la transparencia, una parte importante de la agilidad, mientras que los puntos de historia respaldan la intransparencia.
2.3. Los puntos de historia permiten la planificación póquer
Algunos defensores de los puntos de historia dicen que son necesarios para la planificación póquer, que es un ejercicio de estimación en el que todo el equipo estima el trabajo individualmente y luego compara sus estimaciones.
Sin embargo, la planificación póquer se puede hacer con estimaciones en horas de la misma manera que con los puntos de historia. Por lo tanto, esto no es una ventaja de los puntos de historia sobre las estimaciones en horas.
2.4. Los puntos de historia son más fiables
Algunos defensores de los puntos de historia dicen que es más probable que sean más correctos que las estimaciones en horas. Si eso es cierto depende mucho de lo que entendamos como correcto. Para los puntos de historia, a menudo se dice que las estimaciones son correctas si una tarea estimada en 13 puntos de historia era de hecho más grande que una tarea estimada como una tarea de 8 puntos de historia. Por otro lado, para las estimaciones en horas, no se considera suficiente si una tarea estimada en 13 horas toma más que la tarea estimada en 8 horas, sino que se pregunta si la tarea realmente tomó la cantidad exacta de horas. Entonces estos son dos estándares diferentes. Entonces, si definimos la “estimación correcta” para las estimaciones por hora, como la estimación relativa de horas entre diferentes tareas, entonces no hay ventaja de los puntos de historia sobre las estimaciones en horas.
Los defensores de los puntos de historia dicen que las estimaciones en horas no se pueden hacer con precisión y que las estimaciones en horas pueden variar por muchas razones diferentes.
Sin embargo, los puntos de historia no son de ninguna manera más precisos que las estimaciones en horas. La diferencia está en la expectativa, ya que no se supone que los puntos de historia sean precisos.
2.5. Los puntos de historia permiten una estimación más rápida
Los defensores de los puntos de historia dicen que las estimaciones en puntos de historia son más rápidas y muestran la experiencia de los equipos que han reducido el tiempo de estimación al cambiar de las estimaciones en horas a los puntos de historia.
De hecho, esto puede ser una gran ventaja de la estimación de puntos de historia sobre la estimación tradicional en horas.
2.6. Los puntos de historia limitan la presión de tiempo de la gerencia
Hasta ahora hemos visto que ninguno de los argumentos a favor de los puntos de historia sobre estimaciones en horas es cierto, porque se pueden lograr los mismos beneficios con estimaciones en horas ya que:
● Se basan en un desarrollador estándar
● No se espera que sean precisas
● Se hacen de manera aproximada
Sin embargo, hay una ventaja más de los puntos de historia que generalmente no se menciona: los puntos de historia son más difíciles de controlar para la gerencia. Eso significa que si un desarrollador estima una tarea en 5 puntos de historia y luego toma un 50% más de lo esperado, esto es más difícil denotar para el equipo no técnico o la gerencia. Pero si el desarrollador estima una tarea en 5 horas y luego toma el 50%, o 7.5 horas, esto es visible para todos.
En mi experiencia al decidir entre los puntos de historia y las estimaciones en horas con los desarrolladores durante los últimos 15 años, he visto que esta es, de hecho, la principal razón por la que los desarrolladores prefieren los puntos de historia. Esto se hace evidente en las discusiones abiertas cuando los desarrolladores expresan la siguiente preocupación: “No puedo estimar el esfuerzo de gran parte de la funcionalidad con precisión, y soy consciente de que muchas veces en el pasado estimé de una forma y luego tomó tres veces más. Por eso no quiero que me digas más tarde, que yo tengo la culpa porque las cosas tardaron más”.
En resumen, vemos que la estimación en puntos de historia parece tener ventajas sobre la estimación en horas:
3. Estimación Ágil en Horas
Cuando vimos las ventajas de estimar en puntos de historia sobre estimar en horas, estábamos comparando con la tradicional estimación en horas. Sin embargo, también existe una forma de estimar en horas de forma ágil. La diferencia entre las estimaciones ágiles y las estimaciones tradicionales es la siguiente:
● Las estimaciones se basan en un desarrollador estándar.
● No se espera que las estimaciones sean precisas, sino más bien aproximadas.
● No existe presión por parte de la gerencia para cumplir con las estimaciones de tiempo.
● Las estimaciones se realizan durante la planificación de los ciclos de enfoque, a menudo denominada planificación scrum.
Al comparar los puntos de historia con estimaciones ágiles en hora, la mayoría de las ventajas de los puntos de historia desaparecen, como mostraremos a continuación.
3.1. Método ágil
En primer lugar, los puntos de historia se utilizan generalmente en una manera ágil de trabajar. Pero esto también es cierto para las estimaciones ágiles en horas, que se realizan dentro de la sesión de planificación del sprint. Así que no hay ninguna ventaja para estimación en puntos de historia.
3.2. Estimación independiente del desarrollador
En estimaciones ágiles en horas, la estimación de tiempo se basa en un desarrollador “estándar” o, más generalmente, en un trabajador estándar. Por ejemplo, cuando un desarrollador senior desarrollaría una tarea en 2 horas y un desarrollador junior en 6 horas, podríamos estimar 4 puntos de historia. Asimismo, podríamos estimar en horas y asumir que un desarrollador estándar toma 4 horas. Entonces, si para estimar en horas asumimos un desarrollador estándar, no hay más ventaja de los puntos de historia sobre las estimaciones en horas.
3.3. Estimaciones rápidas
El mayor argumento para usar los puntos de historia sobre las estimaciones en horas es que las estimaciones son más rápidas de hacer. Sin embargo, la diferencia se debe al hecho de que a menudo a los equipos que estiman en horas se les pide que estimen con la mayor precisión posible, mientras que a los equipos que estiman en puntos de historia solo se les pide que asignen un número de puntos de historia preestablecido. Entonces, una estimación más lenta en horas tiene que ver con la precisión esperada. Si a los equipos se les pide que estimen en horas de manera muy aproximada, por ejemplo, seleccionando valores preestablecidos, como se hace en los puntos de historia, no hay razón para que las estimaciones tomen más tiempo.
En la estimación ágil en horas también hacemos una estimación rápida y aproximada sin ninguna expectativa de ser precisos. Por esa razón, las estimaciones se realizan con la misma rapidez que con los puntos de historia.
3.4. Es menos probable que sean incorrectos
La razón por la que los puntos de historia tienen menos probabilidades de ser incorrectos es que la expectativa para ellos es que sean sólo estimaciones aproximadas. Entonces, si estimas 5 puntos de historia y, de hecho, te toma 6 puntos de historia, no considerarías que esto es un error, mientras que podrías verlo como un error en caso de que estimaste 5 horas y te tomó una hora más.
En la estimación ágil en horas hacemos una estimación rápida y aproximada, por lo que no hay expectativa de ser precisos. Entonces, si algo toma una hora más que la estimación original, no consideraríamos que esto sea un error. En otras palabras, es menos probable que seamos incorrectos.
3.5. Sin presión de la gerencia
Con estimaciones ágiles en horas, las estimaciones se realizan sin ninguna precisión. Esto se comunica a la gerencia o al responsable del producto, para que no utilicen las estimaciones para luego presionar a los desarrolladores.
Entonces, si hacemos estimaciones ágiles en horas de la manera correcta con el equipo de gerencia adecuado, entonces no debería haber ninguna presión indebida sobre los desarrolladores.
Entonces, si comparamos las estimaciones en horas realizadas de manera ágil con los puntos de historia, vemos que casi no hay desventajas:
Así que la única pequeña ventaja de los puntos de historia sobre la estimación ágil en horas es que los desarrolladores se protegen aún más de la presión potencial de la gerencia. Esto se debe a que la gerencia no entiende bien como los puntos de historia se traducen en horas, días o semanas.
4. Ventajas de Estimar en Horas Sobre Estimar en Puntos de Historia
Si hay pocas ventajas de los puntos de historia sobre las estimaciones en horas, entonces necesitamos ver si, por otro lado, las estimaciones en horas tienen ventajas sobre los puntos de historia.
De hecho, existen varias ventajas de las estimaciones en horas sobre las estimaciones en puntos de historia:
● Se traducen directamente en el tiempo que tomará
● Tienen el mismo significado para todos
● Son comprensibles para la gerencia y partes externas
● Hacen evidentes los errores en estimación y los retrasos
● Reflejan el progreso
● Se combinan con el seguimiento del tiempo y facturación por horas
4.1. Las estimaciones en horas permiten saber cuánto tiempo tomará una tarea
Cuando usamos los puntos de historia para planificar cuánto trabajo podemos realizar en un sprint, tenemos que comparar los puntos de historia con la velocidad del equipo. Ese proceso se realiza de la siguiente manera:
● Determina cuántos puntos de historia puede lograr un equipo en un sprint (velocidad del equipo).
● Suma los puntos de historia y compáralos con la velocidad del equipo para ver si la carga de trabajo es realista para el sprint.
Este cálculo lleva algo de tiempo, mientras que debe quedar claro cuántas horas trabajará el equipo y la carga de trabajo del sprint permitida es fácil de ver.
4.2. Las estimaciones en horas tienen el mismo significado para todos
Al estimar con puntos de historia, los equipos pueden decidir que una tarea de 100 puntos de historia debe tener una carga de trabajo 20 veces mayor que una tarea de 5 puntos de historia o incluso pueden determinar que 1 punto de historia debe equivaler a 1 hora. Solo si el equipo establece tal definición, los miembros del equipo podrán tener una comunicación clara sobre los puntos de historia. Pero si faltan estas definiciones, entonces un desarrollador podría asumir que un punto de la historia corresponde a aproximadamente 3 horas, mientras que otro piensa que corresponde a aproximadamente 5 horas. Como consecuencia, se comunicarán mal cuando se refieran a los puntos de historia.
El problema se vuelve aún mayor cuando se comunican entre diferentes equipos, ya que cada equipo puede tener una definición diferente de cuánto significa un punto de historia en términos de tiempo.
Las estimaciones en horas siempre tienen la misma definición para todos, por lo que no hay problemas de comunicación.
4.3. Las estimaciones en horas son comprensibles para la gerencia y otras partes interesadas externas y, por lo tanto, conducen a una mayor transparencia
Una ventaja importante de las estimaciones en horas es que cualquiera, incluso si no está familiarizado con scrum y la definición de puntos de historia, puede comprender su significado.
Por supuesto, esto puede ser una desventaja si eres un desarrollador y no quieres que la gerencia te presione en relación con el tiempo de desarrollo del software. Sin embargo, el espíritu de ágil es la transparencia y la colaboración entre el cliente y el desarrollador y entre la gerencia y el desarrollador. Esto significa que se espera que la gerencia y el cliente sean abiertos y transparentes con el desarrollador, pero también que el desarrollador no debe tener nada que ocultar al cliente o la gerencia.
La estimación en horas hace que la estimación sea comprensible para todos y, por lo tanto, contribuye a la transparencia.
4.4. Las estimaciones en horas hacen que los errores de estimación y los retrasos sean evidentes
Con estimaciones en horas, es mucho más fácil ver las desviaciones en el tiempo del desarrollo real con las estimaciones originales. Los desarrolladores de software, que no valoran la transparencia, pueden pensar que esto es algo malo, pero para una organización ágil esto es algo grandioso.
Una organización ágil quiere medir continuamente los resultados, ser autoreflexiva y mejorar, y la apertura en términos de errores de estimación y retrasos ayuda en eso.
4.5. Las estimaciones en horas permiten reflejar fácilmente el progreso
El equipo ágil y la gerencia quieren ver continuamente el progreso del proyecto. Este progreso debe medirse no solo con las tareas completadas, sino también con las tareas en progreso. Por ejemplo, digamos que tenemos 10 funciones planificadas para un sprint y en la mitad del sprint solo se realiza 1 función, pero 8 funciones están entre un 90% de finalización. En este caso, está claro que para obtener una evaluación realista del progreso, debemos tener en cuenta las tareas en curso. Eso significa que tenemos que dividir los puntos totales de historia de las tareas en progreso entre la parte que se ha realizado y la parte que aún queda. Pero esto es más difícil si se utilizan puntos de historia en lugar de estimaciones en horas.
Este es especialmente el caso si durante el trabajo en una función se hace evidente que la estimación de puntos de historia original era incorrecta. Por ejemplo, qué debería hacer un desarrollador si descubre que una tarea de 40 puntos de historia solo le tomó una hora para lograr un estado de finalización del 90%, o ve una tarea que se estimó en 2 puntos de historia que ya le tomó 100 horas para conseguirla a solo el 30% del estado de finalización. ¿Ajusta los puntos de historia originales y los restantes? ¿Y cómo lo haría?
En una estimación en horas, estos ajustes son mucho más fáciles, ya que el desarrollador sabe cuántas horas ya trabajó en la tarea.
4.6. Las estimaciones en horas se combinan con el seguimiento del tiempo y la facturación por hora.
Otra ventaja de las estimaciones en horas es que se combinan con el seguimiento del tiempo y la facturación. El seguimiento del tiempo es necesario para muchas organizaciones, como abogados o desarrolladores, que a menudo facturan por horas. Lo bueno es que podemos usar el mismo sistema para planificar el esfuerzo y luego hacer el seguimiento mientras trabajamos en ello y usarlo para facturar después de haber completado la tarea. Esto es posible porque podemos facturar a los clientes por estimaciones en horas, pero no por puntos de historia.
Podemos ver que hay muchas ventajas de las estimaciones en horas sobre los puntos de historia.
Además, existen algunas, pero pocas, ventajas de las estimaciones tradicionales sobre las estimaciones ágiles en horas.
5. Estimación Ágil en Horas Mejor que la Estimación en Puntos de Historia
Hemos visto que las estimaciones en puntos de historia no tienen ventajas sobre las estimaciones en horas, al menos cuando las estimaciones en horas se realizan de forma ágil, es decir:
● Estimaciones de tiempo:
○ Se basan en un desarrollador estándar
○ No tienen la expectativa de ser precisas
○ Se hacen de manera aproximada
● No hay presión de la gerencia para cumplir con las estimaciones de tiempo.
Por otro lado, hay muchas ventajas de las estimaciones en horas sobre la estimación en puntos de historia.
Podemos comparar todas las ventajas y desventajas en una tabla completa:
La tabla muestra claramente que la mejor manera de estimar el tiempo de una tarea es con una estimación ágil en horas. Por esa razón, internamente ya no usamos puntos de historia, sino que siempre usamos tiempo estimado en horas. Así también, para nuestro software de enfoque y productividad, llamado Workiamo, sugerimos que la persona utilice estimaciones en horas. Sin embargo, damos la flexibilidad para que las personas sigan estimando en puntos de historia, si así lo prefieren.
Workiamo es una herramienta muy simple y es ideal para cualquiera que quiera estar menos estresado y ser más productivo. Al leer esto, ¡te permitimos acceder a él de por vida de forma gratuita! Para ello, debes registrarte en www.workiamo.com introduciendo este código: ILOVEWORK.
