8 errores de estimación ágil que todo equipo debe evitar

La estimación ágil se está convirtiendo en un elemento central de la gestión de proyectos de software. Los equipos de desarrollo usan estimaciones para priorizar el trabajo y establecer cronogramas alcanzables, los propietarios de productos usan estimaciones para configurar product roadmaps y la gerencia usa estimaciones para realizar un seguimiento de los presupuestos. En general, la estimación ágil ofrece muchos beneficios. Pero también requiere que las estimaciones se hagan correctamente. Dado que la estimación ágil, especialmente la estimación de puntos de historia, es utilizada por casi todos los equipos Scrum, siempre hay algunos errores que los equipos cometen intencional o no intencionalmente. En este artículo, enumeramos los 8 errores comunes de estimación ágil que deben evitarse.

1. Medición de la productividad basada en puntos

Uno de los errores o conceptos erróneos comunes en el enfoque ágil es que los puntos se consideran como una medida de la productividad de un equipo o el valor empresarial de la historia, lo cual es totalmente erróneo. Estos conceptos erróneos pueden dar lugar a estimaciones ineficaces o retrasos inesperados.

Un equipo no debe compararse en función de los puntos que completa o su velocidad promedio (es decir, los puntos de historia promedio que un equipo puede lograr en un sprint). Los puntos solo reflejan el esfuerzo requerido para completar una historia, no una medida de la capacidad del equipo para completar la historia en un tiempo determinado.

Aunque los puntos son útiles para la evaluación interna de un equipo para ver los esfuerzos que deben realizar, los puntos se asignan en función de la experiencia pasada del equipo con una historia similar que requirió un esfuerzo similar.

La forma en que los equipos asignan puntos a una historia cambia de un equipo a otro. Un nuevo equipo ágil definitivamente será débil en la estimación de puntos, pero la experiencia gradual y los datos de referencia anteriores pueden hacerlos eficientes y aumentar su productividad. En resumen, la estimación de puntos de valor principal que aporta a un equipo es ayudarlos a estimar cuánto trabajo pueden completar de manera realista en el próximo sprint.

2. Estimación demasiado inteligente

Todos los miembros del equipo en un equipo ágil muestran diferentes niveles de conjuntos de habilidades y experiencias. Algunos de ellos son profesionales y rápidos, mientras que otros son principiantes y lentos. Por lo tanto, a menudo, durante una reunión de planificación de sprint, un miembro del equipo profesional intenta mostrar su capacidad dando menos puntos a una historia, mostrando así menos esfuerzo requerido. Pero debido a esa estimación demasiado inteligente, el equipo en su conjunto no logra el objetivo o lucha arduamente para completar la historia.

En tales escenarios, es importante que los miembros del equipo estén informados de que los esfuerzos que estiman son para todo el equipo, no para un solo individuo. No hay apreciación si estima una historia con menos puntos solo para mostrar su competencia y dejar que el equipo sufra más adelante.

En el modelo comercial tradicional, una empresa aprecia a los empleados que dan expectativas poco realistas en función de su nivel de competencia. Pero el enfoque ágil es completamente diferente, y esa es su belleza. Una vez que una organización adopta un enfoque ágil, la cultura demasiado inteligente se desvanece, mientras que la organización experimenta un entorno de trabajo en equipo más productivo, confiable y realista entre todos los equipos.

Por lo tanto, para evitar que los miembros del equipo estimen historias en función de su competencia, se les debe recordar continuamente que estimen la historia en función de los esfuerzos requeridos por cualquier miembro (profesional o principiante) de un equipo. Podría estar luchando por nuevos equipos ágiles, pero una vez que los miembros aprendan de sus puntos estimados y esfuerzos reales, la estimación se volverá gradualmente más eficiente y centrada en el equipo.

3. Asignación de valores de puntos basados ​​en horas o días

Cuando los equipos cambian a un enfoque ágil, algunos de ellos desconocen cómo funciona la estimación de puntos. Entonces, lo que hacen es asignar puntos a las historias en función de las horas que llevaría completar esa historia. Este enfoque está bien si un equipo está dando los primeros pasos en el mundo ágil. Pero si el equipo se apega a este enfoque durante mucho tiempo, puede comenzar a generar problemas. Pronto deben comprender que el sistema de puntos es una estimación de escala relativa, no una escala de horas.

Para ser claros, “Puntos” es una medida del esfuerzo requerido para completar una historia en particular basada en los esfuerzos que tomaron historias similares en el pasado.

Cuando falla una estimación de puntos basada en horas, la capacidad del equipo para usar la escala de horas se destruye, lo que afecta tanto la productividad como el riesgo de largas demoras. Por ejemplo, un equipo estimó que una historia se completaría en 4 horas, pero les tomó 8 horas completarla. Entonces, comenzarán a entrar en pánico sobre cómo completar la siguiente historia en las horas estimadas, cuando la primera no se completó en las horas previstas.

En resumen, es muy fructífero para un equipo darse cuenta rápidamente de que la estimación de puntos es de escala relativa y refleja los esfuerzos necesarios para completar la historia sin proyectar las horas que tomaría. Sin embargo, la eficiencia en la estimación de puntos también requiere algo de tiempo. Es la experiencia gradual del equipo lo que hace que su estimación de puntos sea eficiente y les permite darse cuenta de su velocidad media.

4. Estimación en una “sentada” o única

Durante una sesión de estimación, una práctica común que realizan la mayoría de los equipos ágiles es intentar estimar todas las historias en una sola sesión. Este enfoque es bueno si hay pocas historias para estimar y todos los miembros del equipo están disponibles para unirse a la sesión.

Pero el mundo corporativo se está globalizando y la tendencia del trabajo remoto debido a la pandemia de COVID-19 también está cambiando la forma en que colaboran los miembros del equipo. Algunos pueden estar trabajando en diferentes zonas horarias, mientras que otros pueden no estar disponibles para asistir a la sesión, lo que provoca que todo el proceso de planificación del sprint se retrase. Además, estimar todas las historias en una sesión de reunión también parece menos eficiente. Se debe a que no todos los miembros son capaces de comprender rápidamente la historia y proporcionar estimaciones, especialmente los nuevos miembros del equipo. Necesitan el tiempo adecuado para comprender la historia y asignar los puntos correctos. Por lo tanto, la táctica de estimación única no parece un enfoque eficiente si un equipo involucra a novatos o miembros que trabajan de forma remota o en diferentes zonas horarias.

Una solución recomendada es proporcionarles a los miembros historias de antemano para que puedan tener una comprensión previa de las historias antes de asistir a la reunión de planificación del sprint. Para ahorrar aún más tiempo, se puede pedir a un equipo que estudie historias y proporcione estimaciones de puntos antes de una fecha límite determinada. Posteriormente, el moderador puede recopilar las estimaciones de todos los miembros y ver si se llega a un consenso. De lo contrario, se puede realizar una sesión rápida para volver a estimar las historias y llegar a un consenso. Este enfoque de estimación de puntos de historia se conoce como Async Poker .

5. Interconexión de valor comercial y puntos

Los equipos ágiles deben tener claro el “Valor comercial” y los “Puntos” y no deben interrelacionarlos para crear confusión.

Si bien un equipo ágil es el que estima el esfuerzo requerido para completar una historia, son los propietarios del producto quienes estiman el valor comercial de una historia en particular y sopesan otras variables.

A diferencia de los puntos, el valor comercial de una historia puede cambiar rápidamente debido a múltiples factores, incluido el enfoque de orden para completar las historias. De hecho, el valor comercial también puede cambiar cuando el equipo está trabajando en el proyecto durante un sprint.

El propietario de un producto puede incluso priorizar el backlog considerando la relación entre el valor comercial y los puntos estimados. Además, también puede desempeñar un papel motivador para el equipo al permitir que los miembros sepan cuánto valor comercial tiene una historia en particular para el propietario del producto.

Dado que el valor comercial puede cambiar en cualquier momento, lo mejor para los equipos ágiles es mantener el valor comercial y los puntos separados unos de otros. Un equipo debe estimar una historia en función de los esfuerzos que requiere, independientemente del valor comercial que tenga para el propietario del producto. De esta manera, un equipo permanece enfocado y productivo, mientras que puede ajustar sus prioridades más adelante según las instrucciones del propietario del producto.

6. Ajuste de valores de puntos

La mala estimación de la historia es un error común que cometen los equipos, especialmente aquellos que han adoptado recientemente el enfoque ágil. El marco ágil tiene muchos beneficios que ofrecer, pero su naturaleza iterativa es una de las principales. Sin embargo, la naturaleza iterativa no significa que los equipos puedan ajustar los valores de los puntos una vez que se dan cuenta de que una historia debe ser subestimada. Si lo hace, simplemente elimina todo el propósito del sistema de estimación de puntos.

Los puntos de la historia son el indicador de cómo el equipo entiende la historia usando su conocimiento y experiencia y luego estima el esfuerzo que requerirá para completarla. Entonces, cuando los esfuerzos reales no coinciden con los esfuerzos estimados, es una experiencia de aprendizaje para el equipo para que puedan estimar correctamente en futuras historias similares. Ese es el objetivo principal a lograr con el sistema de estimación de puntos.

Si un equipo altera los valores de los puntos, básicamente está alterando la historia. Si lo hace, reduce la capacidad del equipo para hacer eficientes sus habilidades de estimación. Entonces, cuando se discuta una historia similar en el futuro, cometerán el mismo error si han alterado los valores de los puntos en el pasado. En resumen, mantenga intactos los valores de los puntos, aprenda de sus estimaciones erróneas y mejore sus habilidades de estimación.

7. Aprender del fracaso

Una vez que se completa una sesión de sprint, un equipo puede sentarse para discutir el rendimiento general del sprint, cómo se desarrollaron las cosas, cuáles fueron los aspectos negativos y otros elementos similares. No hacerlo significa que un equipo no se toma en serio aprender de sus errores de estimación anteriores.

La sesión de discusión posterior al sprint es útil para que los equipos observen más de cerca sus habilidades de estimación de historias y establezcan puntos de referencia para el futuro. Pueden ver qué historias subestimaron o sobreestimaron y cuáles fueron los factores detrás de la variación prominente.

Probablemente, siempre escuchará de equipos ágiles sobre historias que sobreestimaron con un margen muy grande. Por ejemplo, durante una reunión de planificación de un sprint, un equipo se encontró con una historia que incluía una tecnología totalmente nueva/desconocida. Entonces, el equipo estimó esa historia con muy poca comprensión. Pero cuando comenzaron a trabajar en la historia, se dieron cuenta de que la tecnología era fácil de usar y solo requería un esfuerzo insignificante de su parte.

Además, es importante que un equipo esté informado sobre las planificaciones del propietario del producto durante el proceso de desarrollo de la historia y la estimación. De esta manera, no quedarán sorprendidos durante una reunión de planificación de sprint. Una cualidad que debe mostrar un propietario de producto es su discusión previa sobre planes futuros con el equipo durante la sesión de sprint. Un equipo puede hacer diferentes preguntas sobre planes futuros y luego, cuando comienza la sesión de la reunión de sprint, un equipo debe estar bien preparado para proporcionar las estimaciones correctas.

8. Seguir puntos a ciegas

Si una historia no se adapta a las estimaciones, no significa que tengas que seguir ciegamente las estimaciones puntuales durante un sprint. Puede ajustar las prioridades del backlog y cambiar el enfoque a otras historias valiosas.

Entendamos esto con la ayuda de un ejemplo. Considere un equipo que estimó que una historia era sencilla porque pensó que la biblioteca estándar disponible ayudaría a completar la mayoría de las partes de la historia. Según ellos, la simple integración de la biblioteca sería suficiente para encubrir la historia.

Más tarde, los criterios de aceptación de la historia pasaron por encima de las capacidades de la biblioteca. Gradualmente, el equipo pudo comprender que tenían que hacer algo más que la integración de la biblioteca para encubrir la historia. Este concepto erróneo durante la estimación de la historia y ahora la frustración en el equipo afectó la productividad general y también hizo que otras historias del mismo sprint corran el riesgo de retrasarse.

En este tipo de situaciones, seguir los puntos a ciegas resultará en menos productividad y retrasos. Entonces, lo que el equipo o los propietarios de productos pueden hacer es ajustar las prioridades del backlog para sumar el esfuerzo real que la historia exige completar. Pueden ver si hay otras historias con índices de valor empresarial más altos y centrar su atención en ellas para seguir siendo productivos y evitar retrasos inesperados.

Conclusión

La estimación es una práctica imprescindible que realizan los equipos ágiles para mantenerse enfocados y alinear sus objetivos de sprint. Cuando un equipo ágil trabaja en conjunto durante mucho tiempo, su estimación de puntos de historia se vuelve más precisa y realista. Sin embargo, los nuevos equipos pueden y cometerán errores hasta que aprendan de su experiencia. Por lo tanto, asegúrese de que su equipo esté al tanto de los 8 errores mencionados anteriormente y trate de evitarlos tanto como pueda.