Durante la reunión de planificación del sprint, ¿el equipo estima el tiempo para cada historia o las tareas que componen la historia? Entonces, ¿cuál es rastreado por el equipo/scrum master?
Supongo que el equipo estima el tiempo para las tareas que componen una historia, luego la historia es la suma de las tareas. El gráfico de trabajo pendiente (si se basa en el tiempo) se basa en el tiempo restante para las historias...
¿Es esto correcto?
Si bien no existe un requisito formal, la práctica común es estimar las historias de usuario con puntos de historia y tareas en unidades de tiempo . No existe una fórmula canónica para convertir los puntos de la historia en horas ideales.
Los puntos de la historia son estimaciones relativas del nivel de esfuerzo. Por lo general, miden si una historia determinada es más grande o más difícil que otra historia. Los puntos de historia son excelentes para aprovechar el conocimiento multifuncional de su equipo y el tamaño actual de su cono de incertidumbre para proporcionar una métrica adecuada para filtrar qué historias deben encajar en una iteración determinada, pero en realidad no dicen mucho sobre el tiempo .
Una práctica común de Scrum es usar puntos de historia y velocidad histórica para determinar qué historias aceptar en el Sprint actual durante la Planificación del Sprint. Luego, la segunda mitad de Sprint Planning se dedica a convertir las historias en tareas en Sprint Backlog.
Es en este punto que el tiempo suele entrar en la planificación. Algunos equipos brindan estimaciones de tiempo real para cada tarea, mientras que otros equipos pueden simplemente asegurarse de que ninguna tarea exceda un tamaño máximo (a menudo dos días calendario o una cantidad equivalente de horas-hombre ideales). El propósito de esta descomposición es principalmente garantizar que las tareas se realicen o no en el momento oportuno, y permitir que el equipo "falle pronto" cuando una tarea termine siendo más grande o más complicada de lo esperado.
Si su velocidad se mide en puntos de la historia, entonces su tabla de quemado también debería serlo. Hacer una copia de seguridad de las estimaciones de tiempo agregado del Sprint Backlog y comparar la suma con la duración de su Sprint puede actuar como una verificación de cordura de que no ha subestimado sus historias, comprometido en exceso sus recursos o excedido la capacidad de su equipo para la iteración. , pero la comparación es un control de proceso en lugar de un artefacto Scrum requerido.
Si bien la realidad es que cada iteración tiene una cantidad finita de tiempo, la naturaleza de Scrum se presta a muchos regateos durante la planificación del Sprint y dentro de cada Sprint. La teoría subyacente es que, si bien el Sprint Goal es inmutable, las tareas individuales necesarias para completar cada historia pueden cambiarse, agregarse o descartarse según las necesidades del equipo. Debido a la tasa de cambio en las tareas, las estimaciones de tiempo basadas en tareas generalmente no son confiables para fines de planificación ágil .
Agile Estimating and Planning de Mike Cohn puede brindarle una mayor comprensión de las diferencias entre las estimaciones deterministas y las prácticas de estimación ágil. Ciertamente vale la pena leerlo, ya sea que beba o no el ágil Kool-Aid.
jacques chester
Todd A. Jacobs
jacques chester