¿Confunde la precisión con la precisión?
La idea detrás de la estimación Ágil es encontrar un número que sea suficiente, no un número exacto. Es por eso que el uso de puntos de historia para la estimación de elementos atrasados es una mejor práctica; enfatiza el esfuerzo/complejidad en lugar de la duración.
No es necesario saber cuánto tiempo llevará cada tarea necesaria para implementar un elemento atrasado en un sprint. Lo que necesita saber es que, dado el trabajo que se ha comprometido anteriormente en este sprint, ¿puede comprometerse con este elemento atrasado? Debido a que sabemos que no podemos saber exactamente cuánto tiempo tomará cada elemento atrasado, tenemos que hacer una conjetura.
Más importante, ¿qué significa fallar en Scrum? ¿No se está produciendo un error en todos los elementos atrasados del sprint? No ... si has hecho cuatro de cinco ítems y el quinto está casi hecho, obtendrás crédito por los cuatro ítems completados (en términos de velocidad para el sprint), y cuando termines las tareas restantes para ese quinto elemento en un sprint futuro obtendrá crédito completo por ese artículo. Pero, ¿hubieras hecho más si no estuvieras usando Scrum? La única falla en Scrum es no aprender de sus errores, seguir haciendo las mismas cosas disfuncionales repetidamente mientras se esperan resultados diferentes.
Por lo tanto, en su reunión de planificación de sprint, no pierda mucho tiempo preocupándose por algo que no va a poder saber. Deje que el equipo piense sobre el trabajo y luego, inscríbase para la cantidad de trabajo que se sientan cómodos que puedan completar durante el sprint. Si no se cumplen, siempre puedes arrastrar algo a la acumulación o finalizar el sprint anticipadamente.Si se comprometen demasiado, puede terminar los elementos atrasados que pueda en orden de prioridad y analizar por qué los elementos no finalizados no pudieron finalizarse en la retrospectiva de sprint, junto con cómo evitar tener elementos sin terminar en los sprints futuros.
Por cierto, sé que esta fue probablemente una mala elección de palabras de su parte, pero un Scrum Master efectivo no ejecuta el sprint. El equipo ejecuta el sprint y el Scrum Master busca activamente impedimentos que disminuyan su productividad e interfieran con su capacidad de cumplir con sus compromisos. Scrum Masters no son gerentes, son una combinación de árbitro, entrenador y anotador. Ellos son los guardianes del proceso, ayudan al equipo a seguir el proceso, protegen al equipo de agentes externos que intentan sortear el proceso y rastrean el progreso durante el sprint, asegurando que el resumen de sprints se actualice y el gráfico de sprints quemados. refleja la realidad, sobre una base diaria. En la situación que describió, donde el equipo no está seguro de la cantidad de trabajo que debe apuntarse, el Scrum Master debe dejar que el equipo decida como un reflejo del respeto por la propiedad del compromiso por parte del equipo. Cualquiera que sea la decisión, no será incorrecta.
¿Está previsto un pico para el mismo esprint que las tareas que se descubren en la espiga? ¿O están las tareas descubiertas en un pico planeadas para el próximo sprint? –
@Dave generalmente no. por lo general, aumenta un sprint y luego realiza la tarea en el siguiente sprint. Es por eso que es importante asegurarse de dar cuenta de sus picos durante la administración de su versión. – Joseph
+1 @Joseph, diciendo que tienes un pico en un sprint determinado, estás diciendo implícitamente que un pico está en el intervalo de tiempo (es decir, se le asigna una cantidad específica de tiempo fijo). Creo que vale la pena decir explícitamente que los picos deben ser timeboxed. – JeffH