Al elegir las historias más grandes y más pequeñas en una cartera de pedidos para la estimación, ¿cómo impacta cada sprint?

Un artículo que encontré sugería que deberíamos elegir la historia más grande y la más pequeña en la cartera de pedidos priorizada y estimar relativamente las historias restantes. Esto tiene sentido. Sin embargo, me preguntaba cómo funciona esto de sprint a sprint. Por ejemplo, en el próximo sprint, la historia más grande podría tener 5 puntos en comparación con la historia de 8 puntos en el sprint anterior y, de manera similar, la historia más pequeña podría tener 1 en lugar de los 3 del último sprint. Esto parece que puede causar que la velocidad fluctúe de un sprint a otro.

Siento que me estoy perdiendo algo fundamental en la forma de hacer esto correctamente. Buscando a los expertos para aclarar.

Respuestas (2)

La práctica a la que se refiere se denomina comúnmente línea de base. Hay múltiples formas de hacerlo. El que te refieres (el más pequeño y el más grande) es unidireccional. Otro común es elegir una historia que parece bastante intermedia y convertirla en un número medio (quizás un 5), luego estimar todas las demás historias a partir de ella. También sueles hacer comparaciones puntuales de otras historias entre sí y ver si la estimación se cumple (una que es un 8 y una que es un 13 son ambas más grandes que la 5, pero la 13 es más grande que la 8).

Debido a que la línea de base a menudo puede invalidar los números anteriores, no volvería a establecer la línea de base en cada sprint. Encuentro que hacerlo una vez por trimestre o lanzamiento es lo más frecuente que haría, a veces con mucha menos frecuencia.

Por otro lado, vale la pena recordar que la técnica de señalar la historia del usuario fue diseñada específicamente para no ser una ciencia exacta. El propósito era hacerlo liviano para que el enfoque se trasladara a la conversación en el acto de estimar, no a las estimaciones en sí. Estas estimaciones no tienen que ser muy exactas para pronósticos de mediano a largo plazo, por lo que la desviación menor no es particularmente problemática. Solo tomamos una línea de base ocasionalmente para corregir cualquier desviación significativa.

El tamaño de la historia de usuario es una técnica de estimación y al final no se espera que sea exacto. La comparación de historias de usuarios mientras se dimensiona ayuda al equipo a mantener su escala de medición de historias de usuarios pequeñas, medianas y grandes. y ayuda a generar conocimiento consistente para pronosticar. Esto se llama técnica de estimación relativa. La estimación relativa también ayuda a restringir la velocidad de sprint fluctuante. Un ejemplo de estimación relativa sería decir: "Creo que esta función es el doble de compleja que esta otra función". No se menciona el requisito de tiempo, solo que es más complejo que el otro.

Puede decir que la función B es "dos veces más compleja" que la función A, que es una función que ha completado. Debido a que la función A le tomó tres semanas, una suposición razonable para la función B sería de seis semanas.

Entiendo la estimación relativa. Mi pregunta es muy específica para 'Baselines' como mencionó @Daniel.