¿Cómo estimar la velocidad del sprint con diferentes capacidades del equipo?

Somos un pequeño equipo de 4 desarrolladores bastante verdes en Scrum. Viniendo de todo el país, a menudo nos tomamos días libres o semanas completas para ir a casa. Por lo tanto, la capacidad de nuestro equipo cambia drásticamente de una iteración a otra debido a las vacaciones anuales, lo que conduce a velocidades muy diferentes de una iteración a otra. ¿Cómo contabilizamos la capacidad del equipo al estimar la velocidad en la reunión de planificación? Los datos históricos reflejarán capacidades muy diferentes y no podemos esperar un año entero para obtener un promedio de nuestra velocidad estimada.

Puede ser un enfoque simple, pero ¿por qué no calcula su velocidad como completed story points * capacityo completed story points / capacity, dependiendo de cómo mida la capacidad? Si mide la capacidad en horas hombre, use el segundo. Si mide la capacidad como un porcentaje de una semana de 40 horas, use la primera. Cuando vaya a obtener puntos de historia, debe tener una buena idea sobre su capacidad para un sprint determinado, y utilizar los datos históricos de su proyecto para determinar los puntos de historia completados para una carga dada.

Sin embargo, esto hace algunas suposiciones potencialmente peligrosas, como tratar a todos los empleados como iguales: si su desarrollador más joven se toma una semana libre o el desarrollador con más experiencia en el dominio y / o tecnologías se toma una semana libre, su capacidad será la mismo valor numérico, pero el impacto en la velocidad probablemente sería diferente.

En última instancia, utilice el juicio profesional basado en datos históricos al planificar un sprint. En este caso, use la velocidad anterior como entrada en algún otro esquema de estimación, involucrando al equipo. También me equivocaría por el lado de la precaución: es más fácil hacer más trabajo en un sprint que eliminar el compromiso de hacer una tarea.

La velocidad puede variar incluso si la capacidad sigue siendo la misma.

Así que solo confía en tu velocidad, se encargará de la capacidad variable en sí misma, es decir, suponiendo que estés en el tercer sprint, toma el promedio de los últimos dos sprints completos para comprometerte con el siguiente sprint. No te preocupes por la variación en la capacidad.

La velocidad es una guía, no una medida. Simplemente tome el promedio de todos sus sprints (tenga en cuenta la desviación estándar) y el promedio de sus peores tres, el promedio de sus mejores tres y diga "Definitivamente lo haremos, podríamos hacerlo, no lo conseguiremos estas hecho ". Al dibujar tres líneas a través de su cartera de pedidos (totalmente estimada) utilizando estas tres velocidades y su fecha límite aproximada (pretenda que son 12 sprints y 12x su peor velocidad es 75, 12x su mejor es 120 y 12x su promedio es 90. En una cartera de 100 puntos , incluso en el peor de los casos, podría hacer tres cuartos, en el mejor de los casos podría clavar todo y, en promedio, entregaría la mayor parte).

Con estos datos, su OP puede tomar todas las decisiones que necesita en lo que DEBE tener, nos gustaría tenerlo y lo que no le importa dejar de lado.

En definitiva, las cosas cambian, los requisitos son emergentes y, bueno, las cosas volverán a cambiar. No rompas tus habilidades con las matemáticas para obtener una cifra específica, los rangos precisos son suficientes para este tipo de cosas. Explota tus problemas con los problemas de software, no con las matemáticas acumuladas.