La velocidad no se estabiliza con el tiempo, ¿por qué?
11
He trazado el gráfico de quemado de mi equipo y su velocidad por iteración. Para mí se ve muy mal (la velocidad fluctúa mucho). ¿Qué debería estar buscando para diagnosticar la causa raíz de este comportamiento?
¿Por qué se ve mal? La mayoría de los proyectos comienzan con una serie de problemas fáciles de resolver y luego se atascan más tarde, ya que algunos de los supuestos iniciales prueban estar equivocados y deben corregirse para resolver problemas posteriores.
Blrfl
1
¿Tu equipo gana 1000 puntos por sprint?
Bryan Oakley
@BryanOakley Se parece más a 100 puntos / sprint. Considero que la línea superior es el "valor acumulado".
Caleb
Los "puntos" son intencionalmente arbitrarios, incluso si son 1000 puntos por sprint, eso podría significar que un punto es tal vez diez minutos-hombre o algo así.
tdammers
1
@KirkBroadhurst Mira con cuidado. La línea marcada 'Velocidad' en la tecla es de color negro sólido y corresponde a la línea inferior del gráfico. La línea marcada 'Acc. El valor 'en la clave es gris, como la línea superior del gráfico. También puede ver mediante inspección que la línea superior es probablemente el total acumulado de los puntos de datos inferiores: la línea es plana en semanas cuando la línea inferior está cerca de cero (sprints 6, 9, 15 ...), tiene una pendiente constante cuando la línea de fondo es plana (sprints 3-6, 10-13), y nunca disminuye.
Caleb
Respuestas:
20
Es perfectamente normal tener una fluctuación en los primeros diez esprints, mientras el equipo está encontrando su ritmo. Después de eso, es perfectamente normal que la velocidad fluctúe alrededor de un promedio. Intenta trazar un promedio de los últimos cinco sprints más o menos y deberías verlo nivelado. Si no, algunos de los siguientes pueden ser los culpables:
El equipo está tratando de ajustar sus estimaciones de puntos de la historia en función de su velocidad reciente, en lugar de mantener constantes los puntos de la historia y ajustar la cantidad de historias que cuentan.
No estás desglosando las historias lo suficientemente pequeñas.
Demasiadas de sus historias están en las granularidades más altas. Por ejemplo, tiene muchos 20 punteros que no quiere cambiar a 13 o 40.
Tienes muchas historias de "resaca" que no terminan en un solo sprint.
Para las historias de "resaca", ¿qué se supone que debes hacer? Especialmente si el sprint se "completa" al menos para una parte del equipo y luego tienen que arrastrar una historia fuera del sprint unos días antes de que termine el sprint. Por lo que me han dicho, "se promedia". ¿No es esta la forma correcta de pensar?
Earlz
Personalmente, "promediar" está bien para mí, y mi equipo de scrum está de acuerdo. Otros equipos hacen cosas como verificar las historias terminadas, agregar pruebas adicionales, dividir las historias en piezas más pequeñas o acumular historias para evitar resacas, y eso realmente está más en línea con el "scrum puro".
Karl Bielefeldt
Sin embargo, ¿es algo malo tener? Por ejemplo, muchas veces haremos un compromiso únicamente por la velocidad. Commit incluirá muchas historias en progreso, y luego arrastraremos las historias al sprint según sea necesario (y esto es planeado y esperado).
Earlz
Es malo si su código no se puede enviar al final del sprint. Los puristas de Scrum consideran que planear incluir historias en el sprint es malo por principio, incluso si su código se puede enviar al final del sprint. Personalmente, creo que no es malo adaptar el proceso para que se ajuste a su equipo.
Karl Bielefeldt
4
Estás haciendo un mal uso de la velocidad como un indicador de rendimiento, como si cierto número de puntos de historia aceptados fuera un "buen" sprint y algo menos que eso sea un "mal" sprint.
La velocidad (que es un concepto terriblemente mal nombrado) debe usarse como una herramienta de futuro para estimar cuántas características puede comprometer el equipo en el próximo sprint, es decir, la velocidad debe usarse para la planificación de la capacidad.
Aquí hay una cita destacada del artículo: "El problema es el peso dado a la velocidad y convertirla en una medida de productividad".
Puede haber un problema en lo que parece ser una variación significativa en su velocidad. Esto no significa que el equipo esté haciendo algo mal, pero el efecto es que la capacidad del equipo para futuros sprints no se puede predecir muy bien. Desafortunadamente, esa no es una pregunta que ninguno de nosotros pueda responder por usted. Necesita profundizar en el tema a través de la retrospectiva. ¿Qué está pasando realmente?
En cualquier caso, la medida más crítica falta en su gráfico. ¿Qué tan bien hizo el equipo al entregar el valor al que se comprometieron? ¿La velocidad fluctúa porque exceden su compromiso en algunos sprints pero no en otros, fluctúa porque no están terminando las historias o fluctúa porque los compromisos también fluctúan?
Causa potencial adicional: durante los últimos sprints, está pagando la deuda técnica de los sprints anteriores.
Por ejemplo, tiene una demostración de administración después del sprint 3 y necesita mostrar un escenario de día feliz. Para hacerlo, realiza la codificación sin manejo de errores, sin soporte de traducción, sin pruebas unitarias. Esta es una decisión válida, solo necesita estar al tanto de las consecuencias.
Luego, agrega todas las cosas buenas, como el marco de manejo de la extracción, el soporte de traducción, el marco de prueba de la unidad, etc. Su codificación existente de los primeros 3 sprints todavía no tiene uso, por lo que debe actualizarse. Este esfuerzo ralentiza la creación de valor durante los sprints posteriores.
Para su pregunta, es difícil saber por qué tiene fluctuaciones porque podría deberse a la historia, a las personas en el equipo o a la capacidad del propietario del producto. Entonces, en mi experiencia, la velocidad fluctuará porque, por ejemplo:
El miembro de su equipo podría no ser miembros dedicados del equipo. Para trabajar y entenderse, necesitan trabajar juntos el tiempo suficiente. Si su equipo intercambia personas dentro / fuera del equipo con frecuencia, esto hace que el equipo sea dinámico y también afecta la velocidad.
Las cartas de historia son demasiado grandes. Entonces, el equipo no puede entrar en detalles tanto como puede en la planificación / estimación. Encontrarán durante el sprint que algo es más difícil de lo que piensan.
Supongo que estás haciendo scrum. En scrum, tenemos que hacer la planificación de sprint parte 1 (el propietario del producto elige qué hacer) y la planificación de sprint parte 2 (el equipo decide cuánto pueden hacer). Entonces, la situación podría ser, después de que el propietario del producto elija las tarjetas para el sprint, el equipo no profundiza lo suficiente en la parte 2 de la planificación del sprint para que no puedan encontrar el problema oculto que necesitan para informar al propietario del Producto. Si al principio encontraron los problemas, los resolverán O pensarán en cómo deshacerse del riesgo. Esto hace que la estimación sea lo suficientemente correcta antes de comenzar a trabajar en el sprint.
Si las cartas de la historia no están en detalle, la estimación no será precisa. Al principio, la estimación puede ser aproximada, pero antes de comenzar el sprint o antes de que las cartas de la historia vayan al sprint, deben dividirse y aclararse lo suficiente para obtener una estimación casi correcta. Esto ayuda a que la velocidad del equipo sea más estable.
Es posible que el propietario del producto no pueda aclarar las tarjetas de historias lo suficientemente claras antes de comenzar a trabajar en el sprint. Esto también es algo muy importante porque este es el objetivo para que el equipo trabaje en estas 2 semanas. Si el propietario del producto simplemente elige la tarjeta para el sprint y el equipo aún no la comprende, de todos modos debe comprenderlos durante el sprint y la respuesta podría ser que tiene más de lo que discutieron y la estimación es incorrecta. Entonces, esto claramente afecta la velocidad.
etc ...
De todos modos, en mi opinión, no creo que la fluctuación de la velocidad sea importante siempre que sepamos cuál es la situación en cada sprint. La velocidad es solo una cosa para decirle qué tan estable puede trabajar su equipo. Si no es estable, tenemos que averiguar en detalle cada sprint sobre "lo que sucedió". Esta es solo una forma de aclarar / hacer que el problema suceda para que podamos solucionarlo. Entonces, la velocidad solo nos dice lo que estaba sucediendo en ese sprint para que podamos pensar y mejorar para que sea estable. La velocidad es una proyección del proyecto. Y la fluctuación de la velocidad no significa que el equipo no pueda entregar el producto, solo lo ayuda a pensar en la proyección en el futuro y cuáles son los problemas a resolver para que todo sea más fluido.
Tu velocidad tiene ruido (fluctuaciones). Posibles razones:
Las historias son demasiado grandes y, a menudo, una historia a medio terminar se eleva al siguiente sprint.
Las historias no fueron estimadas con precisión. Esto puede deberse a un equipo inexperto o nuevamente a historias demasiado grandes.
Este ruido no es necesariamente un problema en sí mismo: una velocidad ruidosa que fluctúa alrededor de un promedio constante aún le permite hacer una planificación de liberación precisa.
Sin embargo, si filtra el ruido (promedio de rodadura en 5 sprints consecutivos), su velocidad seguirá bajando después de 20 sprints. Hace que sea difícil hacer una planificación de lanzamiento y vale la pena investigar:
¿Es la "definición de hecho" demasiado débil y el equipo está acumulando el trabajo sobrante de los sprints anteriores?
¿La organización está mejorando en desviar el scrum e imponer el trabajo no acumulado al equipo?
¿Las historias grandes (épicas) en la parte inferior del registro posterior se estimaron más optimistas que las historias más detalladas en la parte superior?
Respuestas:
Es perfectamente normal tener una fluctuación en los primeros diez esprints, mientras el equipo está encontrando su ritmo. Después de eso, es perfectamente normal que la velocidad fluctúe alrededor de un promedio. Intenta trazar un promedio de los últimos cinco sprints más o menos y deberías verlo nivelado. Si no, algunos de los siguientes pueden ser los culpables:
fuente
Estás haciendo un mal uso de la velocidad como un indicador de rendimiento, como si cierto número de puntos de historia aceptados fuera un "buen" sprint y algo menos que eso sea un "mal" sprint.
La velocidad (que es un concepto terriblemente mal nombrado) debe usarse como una herramienta de futuro para estimar cuántas características puede comprometer el equipo en el próximo sprint, es decir, la velocidad debe usarse para la planificación de la capacidad.
http://jimhighsmith.com/velocity-is-killing-agility/
Aquí hay una cita destacada del artículo: "El problema es el peso dado a la velocidad y convertirla en una medida de productividad".
Puede haber un problema en lo que parece ser una variación significativa en su velocidad. Esto no significa que el equipo esté haciendo algo mal, pero el efecto es que la capacidad del equipo para futuros sprints no se puede predecir muy bien. Desafortunadamente, esa no es una pregunta que ninguno de nosotros pueda responder por usted. Necesita profundizar en el tema a través de la retrospectiva. ¿Qué está pasando realmente?
En cualquier caso, la medida más crítica falta en su gráfico. ¿Qué tan bien hizo el equipo al entregar el valor al que se comprometieron? ¿La velocidad fluctúa porque exceden su compromiso en algunos sprints pero no en otros, fluctúa porque no están terminando las historias o fluctúa porque los compromisos también fluctúan?
fuente
Causa potencial adicional: durante los últimos sprints, está pagando la deuda técnica de los sprints anteriores.
Por ejemplo, tiene una demostración de administración después del sprint 3 y necesita mostrar un escenario de día feliz. Para hacerlo, realiza la codificación sin manejo de errores, sin soporte de traducción, sin pruebas unitarias. Esta es una decisión válida, solo necesita estar al tanto de las consecuencias.
Luego, agrega todas las cosas buenas, como el marco de manejo de la extracción, el soporte de traducción, el marco de prueba de la unidad, etc. Su codificación existente de los primeros 3 sprints todavía no tiene uso, por lo que debe actualizarse. Este esfuerzo ralentiza la creación de valor durante los sprints posteriores.
fuente
Para su pregunta, es difícil saber por qué tiene fluctuaciones porque podría deberse a la historia, a las personas en el equipo o a la capacidad del propietario del producto. Entonces, en mi experiencia, la velocidad fluctuará porque, por ejemplo:
De todos modos, en mi opinión, no creo que la fluctuación de la velocidad sea importante siempre que sepamos cuál es la situación en cada sprint. La velocidad es solo una cosa para decirle qué tan estable puede trabajar su equipo. Si no es estable, tenemos que averiguar en detalle cada sprint sobre "lo que sucedió". Esta es solo una forma de aclarar / hacer que el problema suceda para que podamos solucionarlo. Entonces, la velocidad solo nos dice lo que estaba sucediendo en ese sprint para que podamos pensar y mejorar para que sea estable. La velocidad es una proyección del proyecto. Y la fluctuación de la velocidad no significa que el equipo no pueda entregar el producto, solo lo ayuda a pensar en la proyección en el futuro y cuáles son los problemas a resolver para que todo sea más fluido.
fuente
Tu velocidad tiene ruido (fluctuaciones). Posibles razones:
Este ruido no es necesariamente un problema en sí mismo: una velocidad ruidosa que fluctúa alrededor de un promedio constante aún le permite hacer una planificación de liberación precisa.
Sin embargo, si filtra el ruido (promedio de rodadura en 5 sprints consecutivos), su velocidad seguirá bajando después de 20 sprints. Hace que sea difícil hacer una planificación de lanzamiento y vale la pena investigar:
fuente