Existe una volatilidad variable entre los equipos de Scrum. Entiendo que la volatilidad puede ser causada por muchos factores variables. La siguiente tabla muestra cuánto varía entre equipos:
Volatilidad de la velocidad Equipo 1 47 11% Equipo 2 68 6% Equipo 3 24 2% Equipo 4 71 14% Equipo 5 34 3% Equipo 6 21 27% Equipo 7 28 7% Equipo 8 32 22%
¿Cuánta volatilidad debería ser aceptable? Entiendo que no puede ser cero.
Acabo de leer sobre "volatilidad" pero, según tengo entendido, no veo mucho de malo en ello. Es una medida de cuán fluido es tu proyecto. Esto es para lo que scrum fue diseñado para manejar.
Yo diría que las razones subyacentes de esa volatilidad son mucho más importantes que su alcance. Como tal, no le pondría un límite estricto, sino algo así como un "límite de advertencia" en el que comienzas a investigar por qué sucede esto. Tal vez use la retrospectiva para determinar si tiene un efecto perjudicial en el equipo y use esas respuestas para guiarlo a un umbral adecuado.
Desde un punto de vista Lean, diría que lo importante no es cuánto es, sino que el equipo sea capaz de cumplir su misión, y quizás que la volatilidad no aumente. En lugar de elegir una métrica como la volatilidad para rastrear, me centraría en comprender el flujo actual del equipo (por ejemplo, usando un tablero Kanban) y solucionar cualquier problema. A medida que comprenda y mejore el flujo, otras cosas a menudo se enderezarán solas.
No se concentre demasiado en la volatilidad. Solo me preocupan los equipos con la volatilidad más baja (que pueden estar jugando con el sistema) como aquellos con alta volatilidad (que pueden estar sobrecomprometiendo/subestimando). Es posible que desee comprender cómo los equipos en cada extremo están llegando a su clasificación. .
Es probable que existan múltiples factores que se aplican a la volatilidad de cualquier equipo. La volatilidad puede provenir de varias causas, tales como:
En promedio, las personas en TI tienden a no tener las mejores habilidades interpersonales. Ciertamente tengo mucha menos habilidad que mi esposa. Formar un equipo efectivo implica interactuar en muchos niveles. Es probable que el buen funcionamiento de un equipo afecte su volatilidad.
Intente ver sus datos: - Ordenados por velocidad - Ordenados por volatilidad - Calcular velocidad/volatilidad - Calcular volatilidad/velocidad
Parece que puede tener dos equipos que están teniendo dificultades. Esto podría deberse a varias razones, algunas de las cuales pueden estar fuera del equipo.
Puede tener cuatro equipos que están jugando a su medida. Pueden estar haciendo un buen uso del tiempo disponible cuando sobrestiman un sprint.
No tiene datos de tendencias que también pueden proporcionar buena información. En general, esperaría que la velocidad aumentara y la volatilidad disminuyera (hasta cierto punto). Cambiar las asignaciones puede romper tendencias.
¿Cuánta volatilidad debería ser aceptable?
Respondería con otra pregunta... ¿por qué le preocupa la volatilidad? Cualquier tentativa de responder lo primero sin pensar en lo segundo podría considerarse BS de gestión.
Sabiendo cómo la volatilidad es importante (o no) en su contexto , entonces puede definir cuál es su límite de volatilidad.
Es como decir '¿cuántos defectos se supone que tiene una historia? Es una buena pregunta, siempre que quieras usar esta información para mejorar. Tal vez tener cero defectos, el equipo está desperdiciando un gran esfuerzo en defectos tontos... tal vez tener 10 defectos de cada historia es demasiado, pero nuevamente, dependerá de su contexto .
alexey r
ssharma