La velocidad del equipo fluctúa mucho, ¿cómo encontrar la causa raíz?

TL; DR

Una velocidad baja pero constante suele estar bien. La velocidad en constante disminución es un fuerte indicador de un problema de proceso no identificado, que el equipo de Scrum necesita identificar y hacer claramente visible dentro del proyecto.

La velocidad es un rango

En primer lugar, la velocidad no pretende ser un objetivo de gestión ni un valor fijo. Es una herramienta de estimación , y es realmente útil para dos cosas:

1. Estimación de horarios.
2. Identificación de cuellos de botella ocultos.

Por sí mismo, el hecho de que tu velocidad fluctúe no importa. Puede usar una herramienta como la Calculadora de rango de velocidad de Mike Cohn , o un promedio final simple, para averiguar cuál es su rango de velocidad normal. Personalmente, me gusta usar el promedio final de 90 días, pero la metodología exacta es menos importante que el hecho de que debe tratar la velocidad como una métrica histórica para predecir intervalos de confianza para estimaciones futuras.

Lo que te dice tu velocidad

No se proporciona suficiente información para que alguien le diga por qué su velocidad tiene tanta variación, pero tiene una tendencia mayormente a la baja, y hay una serie de sprints que produjeron cero puntos. Por lo tanto, uno puede sacar una serie de conclusiones probables.

• Su proyecto tiene una complejidad oculta o sus estimaciones son incorrectas.

  Si constantemente te faltan objetivos de Sprint (no objetivos de velocidad; eso es completamente diferente), es posible que estés subestimando el esfuerzo de trabajo para las historias de usuario, poniendo demasiado trabajo en cada sprint o pagando el precio de la deuda técnica que asumiste. anteriormente en el proyecto.

• Tuviste un éxito temprano, pero chocaste contra una pared.

  Esto puede ser el resultado de una deuda técnica, cambios en el proyecto o cambios en la composición de su equipo. Alternativamente, es posible que haya cambiado su sistema de puntos y que los puntos fáciles obtenidos anteriormente en el proyecto ya no aumenten artificialmente las líneas de su gráfico.

• Estás midiendo las cosas equivocadas.

  Tu valor acumulado siguió aumentando entre los sprints 8 y 14, aunque la velocidad era baja. O su valor acumulado no tiene ninguna relación con el tamaño o el volumen de las funciones entregadas (posible, pero sospechosamente improbable), o está entregando funciones a las que no se les asignan puntos de historia dentro de sus sprints.

Programar objetivos

Centrarse en la velocidad fuera de contexto no envía productos. La verdadera pregunta subyacente que debe hacerse es si es probable que alcance sus fechas objetivo con su velocidad actual. Si su valor ganado es lo suficientemente alto, su propietario del producto podría declarar que su proyecto fue un éxito en cualquier momento dado y llamarlo "suficientemente bueno".

Si sus objetivos de envío están cayendo, entonces su velocidad es solo una señal de que tiene un problema de proceso que no está siendo capturado en Sprint Planning o Sprint Retrospectives. Esta es una falla del proceso.

Lo que puedes hacer

Independientemente de la naturaleza de la falla del proceso, la solución es aprovechar las comunicaciones del equipo para sacar a la superficie esos problemas del proceso. Una vez que se han identificado los procesos defectuosos, el equipo puede tomar decisiones informadas sobre cómo (o si) resolverlos.

Como siempre, los objetivos son la transparencia y la visibilidad . ¡Haga que el proceso y el progreso del proyecto sean completamente transparentes, haga que los problemas sean visibles y luego ponga a funcionar el ciclo de inspección y adaptación de Scrum!

Como señaló CodeGnome, la velocidad siempre será un rango. Sin embargo, si encuentra que su velocidad fluctúa mucho, aquí hay algunas cosas para verificar y sugerencias para mejorar:

1. ¿Tienes en cuenta las vacaciones? Por ejemplo, si ejecuta sprints de 2 semanas, puede tener un sprint con 2 días festivos, que es un 20 % menos de duración que un sprint normal de 10 días laborables. Además, si algunas personas están de vacaciones, tendrás menos capacidad. ¿Es posible que desee ajustar sus sprints durante 10 días hábiles?

2. Mejore su estimación : Quizás su estimación puntual no sea consistente. Algunas personas usan historias de referencia. Por ejemplo, identifique una historia típica como una historia de 1 punto y otra como una historia de 2 puntos y así sucesivamente. Al hacer la estimación, utilícelos para comparar. ¿Esta historia es más compleja/esfuerzo que la historia de referencia?

3. Trabajo desequilibrado : es posible que tenga un trabajo que no esté equilibrado entre los equipos de desarrollo, diseño y pruebas. Esto puede conducir a tiempo de inactividad en algunas disciplinas. La solución aquí es hacer que el equipo sea más multifuncional.
4. Impedimentos : ¿Las historias/tareas se bloquean a menudo debido a impedimentos? Si ese es el caso, realice un seguimiento de los impedimentos, asigne responsabilidades y ajuste su sprint, según sea necesario.
5. Reelaboración : ¿Tienes muchas reelaboraciones? Puede ser que el equipo declare que una historia está completa y el Dueño del Producto pida arreglos, lo que implica volver a trabajar y volver a probar. La solución aquí es escribir criterios de aceptación comprobables por adelantado.

Dibuje una línea que represente el promedio móvil durante ese período, luego dibuje líneas que representen los límites de control superior e inferior en 1, 2 y 3 sigma. Luego analice de nuevo. Su eje Y va de cero a 1000, lo que puede hacer que la variación normal parezca extrema y volátil.

Debe utilizar los límites de control para determinar si tiene una causa especial. De lo contrario, tiene fluctuaciones aleatorias normales.

Una vez que tenga el nuevo gráfico, vuelva a publicar.

CodeGenome, Ashok y David han dado excelentes respuestas.

Lo que sugeriría antes de proceder con un análisis de causa raíz es cuestionar su suposición básica de que existe un problema. Usted dice que para usted la variabilidad en la velocidad de sprint se ve mal, pero ¿tiene esta variabilidad impactos comerciales que justifiquen el tiempo y el esfuerzo para investigar la causa raíz, desarrollar e implementar acciones correctivas y luego monitorear los efectos de esa acción correctiva en proyectos futuros? ?

Veo 4 posibles causas:

• Tal vez el "valor" de los puntos de su historia fluctúe enormemente por razones "políticas", como inflación/reajuste, etc. Vea, por ejemplo, esto:

http://www.industriallogic.com/blog/stop-using-story-points/

Es decir, su equipo puede estar sujeto a inflación política o manipulación de puntos de la historia. Desafortunadamente, en la organización, cualquiera que sea la medida que usemos, tiende a degenerar a medida que las personas intentan maximizar la medida en lugar de producir resultados tangibles. Quizás esto es lo que E. Deming tenía en mente cuando formuló esto:

"Eliminar metas numéricas, cuotas numéricas y dirección por objetivos. Sustituir el liderazgo".

• Su equipo se esfuerza por encontrar una buena comprensión de lo que debería valer un punto de la historia.

• El trabajo varió significativamente causando pérdidas de productividad en algunos períodos debido a tener que aprender y/o resolver problemas asociados con trabajar en un nuevo territorio.

• Su equipo optimiza el "valor ganado" y trata las estimaciones de puntos de historia sin cuidado.