La velocidad del equipo se ralentiza drásticamente hasta el final de un sprint

He notado que la velocidad del equipo a veces se vuelve "negativa" cerca del final de un sprint. Quedan pocas historias/errores triviales, pero se necesitó un esfuerzo extraordinario para terminar. El equipo parece no estar agotado. Pero esto siempre pone en peligro y cambia la fecha de entrega. Lo que he probado:

  1. Microcontrol: da un pequeño impulso, pero estresa a las personas y contra las prácticas ágiles
  2. DYI - funciona pero solo si sabes cómo
  3. Reduzca la capacidad de acumulación de sprint para tener un período de enfriamiento en el que el equipo pueda arreglar todo. - No funciona
  4. Introdujo una línea roja, algo así como una fecha límite interna donde todas las historias deben cerrarse con todos los errores no triviales. - No funciona
  5. Se cambió el lanzamiento a la mitad de un próximo sprint y se aplicó el equipo de extinción de incendios que dejó las tareas de FINISH OFF. - Trabaja pero nadie quiere terminar el trabajo de otros.

Ninguno de los métodos enumerados funciona al 100 % o es satisfactorio desde el punto de vista de las partes interesadas/administración.

¿Alguna idea sobre la naturaleza de las cosas o sugerencias sobre cómo deshacerse del problema?

¿Cuánto duran los Sprints?
¿Ha tenido en cuenta una cierta cantidad de tiempo por sprint para corregir el código heredado? ¿Podría ser que los desarrolladores estén dejando las cosas más difíciles para el final del sprint, y son difíciles debido a problemas de código heredados, y es por eso que lleva mucho tiempo solucionarlos?
¿Qué quiere decir con que la velocidad disminuye hacia el final de un Sprint? ¿Está diciendo que mide la velocidad a diario y espera mantener ese impulso? Si es así, eso parece extremadamente peligroso. La velocidad es una medida de la producción del equipo en la totalidad del Sprint Box. Las fluctuaciones diarias son menos importantes que la consistencia de la velocidad de Sprint a Sprint.
Mi temor adicional es que a lo que realmente se refiere es al trabajo iniciado, parcialmente completado y luego dejado languideciendo a pesar de que la mayor parte del desarrollo se completó. Eso me indica que su definición de hecho no se está cumpliendo y que las historias no son rebanadas delgadas de valor que se están llevando a cabo. ¿Puede describir una historia de usuario típica que su equipo deje sin completar?
NielsvanReijmersdal depende de un proyecto y una fase. Típicamente 2±1 semanas. @YvonneAburrow sí, hemos reducido la capacidad de registro de sprint back para tener tiempo de trabajar con el legado, la refactorización adicional (historias tecnológicas) y las sobras. Bueno, siempre estamos descomponiendo las historias en una porción mínimamente valiosa. También significa que el burndown se actualiza todos los días. Por lo tanto, existe la posibilidad de tener una velocidad diaria aproximada, pero tiene razón, no puede ser igual o constante, incluso en un sprint. Aquí hay un ejemplo de Definición de done pastebin.com/yuxfU5hx . Estaré encantado si me ayudas a mejorarlo.
@Venture2099 Ejemplo de una historia: como usuario de habla francesa, quiero tener la localización en francés para el portal xxxxx para poder tener una mejor experiencia de usuario. Nota: Esa no es una historia trivial para el administrador de contenido. Tenemos 3 sistemas que funcionan de forma independiente en un portal y uno de ellos tiene la localización en las propiedades del portal, los contenidos web e incluso el código duro. A pesar de que la historia va mucho más allá de ser un hueso duro de roer, no se entrega la semana pasada. Tenemos la misma historia de localización en el pasado y conocemos todas las rocas submarinas.
Esa no es una historia de usuario; esa es una solicitud de función completamente integrada. El equivalente sería "Como hablante de inglés, quiero ver todo Amazon en inglés". Esa no es una historia de usuario. Además, "una mejor experiencia de usuario" no es un resultado comercial.
Sugeriría volver a los primeros principios y estudiar los Patrones para dividir historias de usuarios que se encuentran aquí. agileforall.com/2012/01/new-story-splitting-resource
@ Venture2099 ¿Cómo crees que debería ser la historia en mi caso? Básicamente, contiene los 3 componentes de la historia de usuario. ¿Quién? ¿Qué? ¿Por qué? ¿Por qué una mejor experiencia no es un resultado comercial? Por ejemplo, puede decir que aumentar la conversión/ventas/SEORanking es el resultado comercial. Pero en este caso no podemos aplicar eso, ya que el producto es único y altamente específico, por lo que tiene el 100% del monopolio en un mercado y es muy conocido en su mercado específico en todo el mundo. Y los usuarios de Francia se ven obligados a usar la versión en inglés. Por cierto, ¡gracias por la genial guía de división!
Además, el producto que desarrollamos contiene algunos mecanismos y arquitectura para la localización y ya tenemos 2 idiomas.
Una mejor experiencia de usuario no es una declaración de valor comercial. Es una opinión subjetiva sobre la implementación. ¿La mudanza de Twitter a los corazones de las estrellas es una mejor experiencia para el usuario? Estoy seguro de que alguien lo pensó, pero no es una declaración de valor comercial que pertenezca a una historia de usuario. La declaración de valor comercial es poder lograr algo. Como USUARIO del Portal de Alexander Averchenko, quiero poder ver la página de inicio en francés para poder seleccionar la opción de menú correcta. [1 historia de usuario].
La colección de Historias de usuarios requeridas para una traducción completa del idioma conforman Epic.

Respuestas (5)

Estás usando el término velocidad de una manera extraña. La velocidad es la cantidad de esfuerzo que un equipo puede poner en desarrollar historias por sprint. Por lo general, se mide en puntos de historia. El promedio de la velocidad sirve para la planificación del lanzamiento o para guiar durante la planificación de Sprint cuánto trabajo se puede realizar en un sprint.

Suena más como si estuvieras hablando de algún tipo de Burndown Chart. Aquí es importante distinguir si está viendo un Gráfico de avance de tareas o un Gráfico de avance de historias.

Si la velocidad se vuelve negativa o se ralentiza drásticamente, probablemente signifique que el Burndown Chart está subiendo en lugar de bajar. Si ese es el caso, eso sugiere dos cosas:

  • Inicialmente has subestimado la cantidad de trabajo
  • Existen impedimentos que hacen imposible realizar el trabajo.
@Alexander Averchenko, ¿podría verificar lo que quiere decir cuando habla de a) velocidad yb) velocidad que se vuelve negativa?
Gracias por la actualización de la teoría, "negativo" es una hipérbole. Estamos usando pequeñas historias para tener una actualización diaria de trabajo pendiente. Entonces puedo ver cuánta historia se cierra diariamente para tener una fuente duplicada de información de salud del proyecto además de las reuniones diarias.
Honestamente, no me preocuparía por el "desgaste diario" y enfocaría al equipo en una victoria simbólica, como un equipo multifuncional, lograr que muevan una historia completa a la columna Listo antes de hacer cualquier otra cosa.

Quedan pocas historias/errores triviales, pero se necesitó un esfuerzo extraordinario para terminar. El equipo parece no estar agotado. Pero esto siempre pone en peligro y cambia la fecha de entrega.

y

equipo entiende que hay un problema. Pero piensa que es un orden natural de las cosas y no conoce la causa raíz y prefiere dejar las cosas como están.

¿Su equipo por casualidad está lleno de tipos de personalidad que dependen y/o prosperan con la presión de una fecha límite para hacer las cosas?

No parece que estén de acuerdo en que hay un problema. Un "problema" no es realmente compatible con el "orden natural de las cosas".

Ya se han mencionado las únicas soluciones de proceso que se me ocurren: fecha límite interna, límite WIP estricto, entrega secuencial de historias (mi equipo las llama "sub-sprints").

Pero parece que lo que realmente tienes es un problema de motivación, y que las entregas tardías y en peligro son un problema para ti pero no para ellos . Entonces, ¿cómo puedes hacer que les importe? ¿Experimentan alguna consecuencia negativa por las entregas tardías? ¿Puede proporcionar recompensas por entregas a tiempo o antes de tiempo? ¿Puede señalar (¿o hacer que alguien más lo haga?) el riesgo para la reputación del equipo entre la alta dirección si este es su patrón?

Limpieza de terminología

La velocidad debe entenderse como una medida del incremento de software "Terminado" que produce el Equipo de desarrollo. Esto se debe a que es mucho más importante medir esto que la "velocidad" de la tarea, el paso del flujo de trabajo, etc.

Ahora que estamos hablando de "Terminado", es decir, la definición de "Terminado" en Scrum, hablemos sobre cómo reducir el riesgo de que las cosas no se "Terminen" al final del Sprint. En breve:

Descomponga sin piedad pedazos grandes de cosas en pedazos más pequeños

La guía Scrum incluye el esfuerzo en los cuatro aspectos de cada elemento del Product Backlog. El tamaño del trabajo está relacionado con esta medida. He notado una correlación entre el trabajo arriesgado y el grande. Para reducir la probabilidad de que el trabajo no se "Termine", divida constantemente el trabajo en la parte superior de la cartera de pedidos en partes cada vez más pequeñas. Me gusta mucho este artículo para buenas técnicas de descomposición .

Obtenga piezas más pequeñas de cosas "hechas" más rápido

Haga que los elementos de la cartera de productos sean pequeños y valiosos (también busque los criterios INVEST para obtener más ayuda sobre la creación de PBI).

Concéntrese como un maníaco en hacer los artículos pequeños rápidamente antes de pasar a otros nuevos, es decir, mantenga las unidades de trabajo pequeñas y limite despiadadamente el WIP hasta que se pueda observar un WIP óptimo. Mire este video para comprender mejor cómo se ve el WIP óptimo:

https://www.youtube.com/watch?v=W92wG-HW8gg

¿Qué logra esto?

El riesgo de cada incremento de software se aborda y elimina mucho antes de que finalice el Sprint. Por lo tanto, el riesgo encontrado al final del Sprint se reducirá y los pronósticos del Equipo de Desarrollo serán más precisos.

Cuando leo "cerca del final de un sprint", significa que tus sprints son demasiado largos. Necesitas acortar tus sprints. Eso es lo principal en lo que debes concentrarte. Tienes la respuesta dentro de tu pregunta.

Dio una explicación bastante clara de lo que sucede y de las acciones que ha tomado para resolver los problemas, pero no sabemos por qué sucede esto, por lo que es difícil dar una respuesta.

¿Tienes alguna idea sobre esto? ¿Ha intentado abordar el problema durante la retrospectiva? ¿Cuál es su papel en el proceso?

-- actualización basada en este comentario --

equipo entiende que hay un problema. Pero piensa que es un orden natural de las cosas y no conoce la causa raíz y prefiere dejar las cosas como están.

Puede que me equivoque y probablemente me esté perdiendo algo (por ejemplo, todavía no está claro cuál es tu rol, supongo que eres el Scrum Master), pero lo que haría en este caso es:

  1. Involucre al equipo en una discusión sobre el problema y, si es necesario, traiga a alguna parte interesada para que aporte su punto de vista. Si el problema existe, debe abordarse, a pesar de que lo consideren importante o no.
  2. Trate de implementar algunas acciones para permitir que el equipo entregue cada historia secuencialmente. Esto puede conducir a un escenario aún peor a corto plazo, pero al menos le permite tener una idea más clara de dónde está el problema y tomar las medidas adecuadas.

En cualquier caso, trabajaría en la comunicación para que todas las personas involucradas tuvieran una comprensión compartida de la situación.

Supongo que si supiera por qué, no iría aquí a preguntar. Soy práctico PM/SM. Las retrospectivas no dieron nada para este tema.
¿Podría explicar qué significa "no dio nada"? ¿El equipo ve el problema pero no puede entender por qué o ni siquiera lo percibe como un problema? El caso es que, sin el más mínimo conocimiento de por qué sucede esto, tratar de encontrar una solución es como disparar al aire con la esperanza de que un pájaro se cruce en el camino de la bala. E incluso si encuentras una solución, no podrás entender por qué funciona...
Significa que el equipo entiende que hay un problema. Pero piensa que es un orden natural de las cosas y no conoce la causa raíz y prefiere dejar las cosas como están. Una vez más, si supiera por qué sucede, podría encontrar una solución. Es por eso que vine aquí para preguntarle a las personas que estaban en una situación similar y encontrar una causa.
Esto ya es algo, actualizaré mi respuesta en base a eso. :)
La velocidad del equipo se ralentiza drásticamente hasta el final de un sprint
RespuestasAquíPolítica de privacidad1y, 0v