¿Cuál es la mejor manera de estimar los puntos de la historia en scrum?

Me gusta cómo funciona la planificación del póker al comienzo de cualquier proyecto, permitiéndole comparar y discutir los detalles de cada historia entre ellos.

Uno de los problemas que he notado con esto es que a través del tiempo y a medida que gana más experiencia con el dominio del problema, tiende a votar menos puntos por cada historia, es decir, una historia que valía un 5 o un 8 al principio del proyecto ahora podría valer un 3.

¿Cómo evita o aborda este problema de la mejor manera posible? ¿Hay una mejor manera de estimar? ¿Deberían las historias permanecer siempre iguales, o los puntos de esta historia disminuyen bien?

No creo que sea un gran problema.

Hay dos cosas obvias que podrían estar causando eso. Una es que estás experimentando una leve deflación puntual. La otra es que su equipo se está volviendo más rápido. (¡Espero que sea lo último!)

De cualquier manera, no debería ser un gran problema. Los dos usos principales de la velocidad son determinar cuánto trabajo realizar en la próxima iteración y hacer estimaciones aproximadas de las fechas de entrega para grandes porciones de trabajo. Ninguno de los dos se ve perjudicado por una velocidad que cambia gradualmente. De hecho, si la velocidad mejorada viene de mejorar, entonces sus nuevos números presentan una imagen más real de la capacidad del equipo.

Si la velocidad está cambiando demasiado rápido para la comodidad, entonces una respuesta son las historias canónicas. Repase los últimos dos meses, escogiendo 3 historias cada una para representar los niveles de puntos que usa. Ponlos en la pared donde haces estimaciones. Luego, como lo estima, úselos como comparación con la historia que está tratando. Eso debería reducir tanto la deriva como la volatilidad en sus estimaciones.

Básicamente, esto no es realmente un gran problema, ya que la mayoría de estas cosas saldrán a la luz. En general, la manipulación explícita del resultado de las estimaciones será negativa para el proceso. La estimación de los puntos de la historia funciona mejor cuando los equipos mantienen sus ojos en la pelota: está estimando la complejidad relativa de las historias en comparación con otras historias, y siempre que tenga información histórica a mano para las historias completas, es probable que vea cómo se resuelven las cosas a largo plazo. Aquí hay un lugar donde la cohesión del equipo paga beneficios, ya que un equipo finalmente se decidirá por métodos e historias de referencia para la estimación de la historia.

Sin embargo, la deflación del punto de la historia puede ser un problema leve, ya que a medida que se comprime su rango de puntos estimados, comienza a perder información sobre el ajuste fino de la velocidad, y esa compresión puede tener efectos negativos al estimar la longitud para la entrega de una liberación a largo plazo planificación (en la medida en que vas a multiplicar los errores introducidos por la compresión de todas tus historias en un rango estrecho). En general, desea que los resultados de una mayor velocidad debido a la experiencia se expresen como asumir más puntos de la historia en lugar de que las estimaciones disminuyan. La forma de combatir eso es hacer referencia continua a estimaciones completadas anteriores y asegurarse de que siempre esté estimando la complejidad. Nunca digas cuánto tiempo crees que tomará algo, solo compara la dificultad general de una historia en comparación con historias anteriores. Dejar' Supongamos que tiene una aplicación que admite plataformas móviles y que tiene que portar a otra. ¿Es similar a un puerto anterior? ¿Más difícil, porque la plataforma tiene herramientas peores? ¿Más fácil, porque tienes un mejor depurador? Eso debería informar sus estimaciones, no el hecho de que este puerto probablemente irá más rápido porque sus equipos se están volviendo buenos en las estimaciones. Concentrarse en la complejidad debería ayudar a resolver este problema, en la medida en que haya uno.