Seis señales de que la aceleración de su equipo es demasiado buena para ser verdad

Permítanme decir desde el principio que soy un gran fan de la velocidad de seguimiento en Scrum ... es un concepto increíblemente poderoso.

• La capacidad de medir el rendimiento del equipo de un sprint a otro permite a un equipo experimentar sistemáticamente con diferentes mejoras del proceso y mejorar sistemáticamente con el tiempo.<
• Una idea clara de la cantidad de resultados que el equipo produce realmente en un sprint también permite tomar decisiones más acertadas sobre cuándo esperar la finalización del proyecto sin que el equipo que lo está desarrollando se convierta en un esclavo.
• Como líder ágil, me gusta saber si mis equipos están acelerando, desacelerando o permaneciendo estables en el tiempo. Si están acelerando, me da confianza en que nuestras fechas de finalización previstas son relativamente seguras; mientras que si se mantienen estables o desaceleran, implica un mayor riesgo en las proyecciones actuales.

1. Velocidad siempre aumenta - Incluso los equipos de mayor rendimiento Scrum sufren contratiempos o encuentran nuevos impedimentos. En general, los equipos de scrum que se fijan objetivos exigentes deberían esperar fracasar en aproximadamente 20% de sus sprints, lo que significa que la velocidad debería disminuir con respecto al sprint anterior en aproximadamente el mismo porcentaje de tiempo (si se está utilizando "el tiempo de ayer" para introducir historias en el sprint). Si su equipo ha pasado por una docena de sprints sin un solo retroceso en la velocidad, esto sugiere que la tendencia al alza se está gestionando más deliberadamente de lo que debería.
2. Aceleración inexplicable - La velocidad puede aumentar en ráfagas cortas sin ninguna razón en particular, pero es difícil mantener una mejora estructural de la velocidad sin eliminar sistemáticamente los impedimentos del equipo. Por lo tanto, si la velocidad de un equipo ha aumentado de forma constante pero no pueden señalar los impedimentos específicos que han eliminado, es una señal de alarma de que la aceleración puede no ser real. En el mejor de los casos, el equipo no está llevando a cabo experimentos de procesos saludables para ofrecer una aceleración repetible y sostenible. En el peor de los casos, pueden estar socavando el significado de su velocidad.
3. La misma historia recibe ahora una mayor estimación de puntos que antes - Esta es la definición de "inflación de puntos" que siempre señalan los detractores de medir la velocidad en puntos. En la práctica, rara vez vemos casos atroces de inflación de puntos en los que exactamente la misma historia que tenía 3 puntos en un sprint anterior ahora tiene 5 puntos en el actual. En cambio, solemos encontrar formas más matizadas de inflación, como cuando se añade una comprobación de calidad adicional para corregir problemas anteriores y se añaden puntos para completar este trabajo adicional. La cantidad de esfuerzo necesario para completar el trabajo puede haber aumentado, pero la cantidad de producción no, por lo que estos puntos añadidos representan una forma sutil de inflación de puntos.
4. Relleno de atrasos con "historias de relleno" - Los equipos que se esfuerzan por aumentar la velocidad a menudo se obsesionan con asegurarse de que todo lo que hacen se refleja en el backlog. En general, no conviene hacer toneladas de trabajo fuera del backlog y sí centrarse en completar los objetivos del sprint. Sin embargo, un cierto nivel de trabajo de limpieza e higiene del equipo es una parte natural del proceso de grupo. Si incluir estos elementos en el backlog ha sido siempre una norma del equipo... está bien. Si no fue siempre la norma, entonces incluir estas historias de relleno con puntos asociados da la falsa impresión de que el equipo está acelerando cuando en realidad no está produciendo más.
5. Muchas historias separadas de tamaño mínimo - A menudo decimos que las historias de usuario más pequeñas son mejores y que, en última instancia, los equipos deberían esforzarse por trabajar con historias uniformemente pequeñas en el sprint. Es un gran objetivo, pero puede llevarse demasiado lejos. Si el trabajo se divide en muchas historias que son más pequeñas que el incremento de tamaño más pequeño utilizado por el equipo ("xs", "1-punto", "Chihuahua", etc.), entonces el error de redondeo de sumar todas estas historias fraccionarias comienza a ejercer una fuerte influencia al alza sobre la velocidad. Si estas historias divididas con precisión siguen siendo buenas historias de usuario que reflejan una funcionalidad incremental, entonces es el momento de reajustar su historia de referencia para dar cabida a divisiones más pequeñas. La mayoría de las veces, sin embargo, estas historias diminutas son en realidad tareas y están perjudicando la capacidad del equipo para trabajar juntos para producir un producto de calidad.
6. - El seguimiento de la fuerza del equipo en cada sprint es útil para conocer el contexto en el que opera el equipo. Hay una serie de razones de peso para aplicar un nivel ligero de normalización al número de velocidad bruta de un equipo para obtener un mejor predictor de la producción real del equipo: proporciona una medida más estable de la producción frente a enfermedades graves, vacaciones, bajas familiares y otros cambios significativos en la capacidad del equipo. Sin embargo, también introduce una palanca más que puede aumentar artificialmente la velocidad aparente, por lo que los equipos deben tener cuidado de reservar los ajustes de normalización sólo para impactos importantes en la capacidad, y no tratar de ajustar cada cambio percibido en la fuerza del equipo. Si observa que el equipo no ha estado a plena capacidad durante mucho tiempo, es el momento de cuestionarse si puede estar produciéndose un exceso de normalización.