¿Cómo estimar tiempos durante Sprint Planning?

Tengo 6 historias de usuario para un sprint de 14 días. Tengo la descripción detallada en las historias de lo que el equipo necesita desarrollar, y el equipo es nuevo en Scrum. (este sería su segundo sprint). Lo único que no he hecho hasta ahora es asignar una estimación a las historias, utilizando un enfoque sistemático. (como un sistema de puntos). Quiero comenzar con el enfoque de póquer de planificación Agile, pero ¿cómo asigno una cantidad de días después de que el desarrollador asigne un tamaño (número, color, etc.) a una historia? Mi punto es ¿por qué necesitamos tener un sistema de puntos si eventualmente vamos a estimar en términos de días?

Respuestas (3)

La idea de los puntos de la historia es que te permiten medir cuánto haces normalmente en un sprint. Luego, usa esta medida para determinar la capacidad de futuros sprints.

Digamos que estás a punto de iniciar un sprint. Su equipo puede elegir entre dos formas de estimar cuánto trabajo se realizará en el sprint:

Estimación basada en el tiempo

El equipo analiza cada historia y calcula cuánto tiempo cree que tardará en completarse. También calculan cuánto tiempo está disponible en el sprint. Agregan historias al sprint hasta que la suma de las estimaciones de las historias agregadas es igual al tiempo que creen que está disponible.

Estimación de puntos de historia

El equipo estima las historias utilizando el tamaño relativo. Podrían usar pequeño/mediano/grande o podrían usar los números de secuencia de Fibonacci (1, 2, 3, 5, 8, 13). Los valores reales utilizados no son importantes. Lo importante es que las historias que requieren una cantidad similar de esfuerzo tienen estimaciones similares. por ejemplo, dos pisos estimados en 5 puntos requerirán aproximadamente la misma cantidad de trabajo para completarse.

Ahora el equipo simplemente se dedica a hacer algo de trabajo. Pero lo inteligente es que miden cuánto hacen en un sprint. Luego usan esta medida para determinar su capacidad para futuros sprints.

Digamos que el equipo trabaja para un sprint y completa 20 puntos de historia. Hay una buena posibilidad de que en el próximo sprint también hagan alrededor de 20 puntos de historia (siempre que su tamaño sea consistente).

Observe cómo nunca se menciona el tiempo. Es simplemente dimensionamiento relativo y medición de cuánto se hace.

Creo que lo estás haciendo mal. No debería molestarse en asignar el número de días a la historia. Su equipo tiene 14 días para trabajar en las historias. Por lo tanto, estimar los puntos de las historias es su forma de decidir cuánto trabajo se puede completar durante esos 14 días. Si el total de puntos para un solo sprint es demasiado grande o demasiado pequeño (lo sabe al reflexionar sobre sprints anteriores), es posible que deba ajustar la cantidad de historias para que pueda entregar lo que "prometió" en 14 días. Creo que ese es el camino a seguir para implementar Scrum. Asignar un número de días a las historias en función de su tamaño no es un paso obligatorio; ni siquiera es útil.

PD: si necesita hacer un seguimiento del tiempo, esa es otra historia. Intente leer estas preguntas y respuestas para empezar: Scrum: ¿es una buena práctica establecer el trabajo restante de una subtarea?

Será difícil estimar cuántas historias puede hacer en el segundo sprint. Particularmente con un nuevo equipo. Úselo como una oportunidad para practicar la estimación de puntos y luego use la cantidad de puntos completados ( implementados en producción ) para determinar cuántos puntos obtener en el tercer sprint.

Sin embargo, aquí está la cosa... Los datos de un solo sprint son prácticamente inútiles. Un solo punto de datos simplemente no es suficiente para pronosticar con precisión. También estarán equivocados acerca de cuán grandes son las historias. No estarán de acuerdo sobre cuán grandes son las historias. Los problemas sucederán, espéralo y no te precipites cuando no terminen tantos puntos en el 3°, o cuando terminen el doble en el 4°. Tomará tiempo para que un nuevo equipo encuentre el punto óptimo y su ritmo, pero lo harán... eventualmente.

En perspectiva, le tomó a mi equipo una docena de iteraciones para lograr una capacidad estable, predecible y pronosticable . Eso son seis meses . No esperes milagros. Simplemente registre los datos, reflexione y adáptese en consecuencia.