Alinear el valor de los puntos de la historia

Hemos terminado con un peso no lineal de nuestros puntos. Me preocupa que esto haga que informar datos de velocidad sea erróneo. Antecedentes:

  1. Se utiliza una baraja bastante tradicional :?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ∞
  2. Solo el extremo inferior de la escala se usa para estimaciones de historias, rara vez superamos los 5 puntos y solo tuvimos un punto de trece.

  3. El valor de puntos es inconsistente entre historias de diferente tamaño. Es decir, los de un solo punto usan puntos "más ligeros" y los de ocho puntos usan puntos "más pesados":

    • 1p: agregue texto de información sobre herramientas a un par de iconos; formato de cadenas de fecha y hora
    • 3p: crea un nuevo rol de usuario y especifica sus permisos; crea automáticamente un nuevo caso en CRM cada vez que se realizan ciertas acciones
    • 5p: funcionalidad de lista de seguimiento; funcionalidad de filtrado en varias facetas
    • 8p: integre con un proveedor externo e introduzca una capa de persistencia para almacenar en caché sus respuestas

En un scrum de libro de texto 1x 8py 8x 1pdebería requerir el mismo esfuerzo, de hecho, ¡esto es exactamente lo que estoy tratando de lograr! Sin embargo, en nuestros ejemplos estimados proporcionados, "integrar con un tercero" es mucho más difícil que "agregar una información sobre herramientas... 8 veces". Así en nuestra planificación de sprints 1x 8p ≠ 8x 1p.

¿Cómo puede nuestro equipo romper el "anclaje" a esta práctica de estimación? ¿Cuál es la mejor manera de señalar y abordar esta inquietud?

¿Puede explicar un poco más qué quiere decir con in sprint planning 1x 8p story is not the same as 8x 1p stories.En términos de esfuerzos, ambos requerirían los mismos esfuerzos para completarse?
@AzizShaikh: en nuestras estimaciones, 1x 8p ≠ 8x 1p. Estoy de acuerdo en que en un scrum de libro de texto deberían requerir el mismo esfuerzo, de hecho, ¡esto es exactamente lo que estoy tratando de lograr! Sin embargo, en nuestros ejemplos estimados proporcionados, "integrar con un tercero" es mucho más difícil que "agregar 8 información sobre herramientas". ¿Alguna sugerencia de cómo puedo expresarlo para que quede más claro?
Puede editar la pregunta y agregar la mismaI agree that in a textbook scrum they should require same effort, in fact this is exactly what I'm trying to achieve! However in our estimate examples provided, "integrating with a third party" is a lot more difficult than "adding 8 tooltips"
Con respecto a 1x 8p ≠ 8x 1p, supongo que el equipo debería revisar su estimación. Tal vez esté dando estimaciones altas a las historias más pequeñas, por ejemplo, agregar 8 información sobre herramientas se debe estimar en 1 punto de historia en total.
Esto puede no estar mal. Las historias tienen sobrecarga, por lo que 8 historias de 1 punto generalmente requerirán más horas-hombre que 1 historia de 8 puntos. Los puntos de la historia miden la complejidad relativa, no el tiempo.
@CodeGnome: en mi humilde opinión, está bien, ya que los puntos no deben asignarse directamente a horas-hombre, sino indicar una complejidad de historia agregada + tamaño + incertidumbre. ¡Algo así como medir el trabajo en unidades de luz solar!
¿Es esto debido a la sobrestimación de sus pequeñas tareas. Es decir, la pieza de trabajo más pequeña debe ser 0,5 o 1/2, es decir. agregar texto de información sobre herramientas.

Respuestas (1)

Tenga en cuenta que estimar los puntos de la historia se trata de obtener el mayor beneficio por esfuerzo realizado. Sabemos que las estimaciones no van a ser correctas, sin embargo, también sabemos que ninguna cantidad de esfuerzo adicional hará que sean correctas. Entonces Scrum intenta optimizar el esfuerzo eligiendo un método simple y fácil para obtener estimaciones relativamente buenas.

Creo que las preguntas en tu caso son:

  1. ¿El sesgo asumido en sus estimaciones afectará su velocidad lo suficientemente fuerte como para hacer que la planificación de lanzamiento no sea confiable?
  2. si es así, ¿cómo corregirlo?

Re 1,

  • (Como también notó) los puntos de historia dan una estimación relativa, no absoluta, por lo tanto, por ejemplo, duplicar los puntos de historia para cada elemento también duplicaría su valor de velocidad, pero nada de esto afecta la velocidad real de su equipo, es decir, cuánto pueden realmente completo por sprint.
  • "Subestimar el tamaño relativo de las historias más grandes" también puede expresarse como "sobreestimar el tamaño relativo de las historias más pequeñas".
  • Las tareas más grandes obviamente afectan la velocidad más fuerte que las tareas más pequeñas.

De estos, mi conclusión es que mientras

  • el sesgo en su estimación es consistente por tamaño de artículo (es decir, subestima o sobreestima artículos del mismo tamaño más o menos de la misma manera), y
  • la desviación del tamaño promedio de los elementos entre los sprints no es grande (es decir, no tiene un sprint con elementos en su mayoría grandes, y luego el siguiente lleno de elementos pequeños),

el valor de la velocidad calculada puede, de hecho, resultar más pequeño que el "ideal", sin embargo, dado que la mayor parte de las tareas se subestiman correspondientemente, los dos errores se cancelarán más o menos entre sí. Entonces, al final, encajará más o menos el mismo número y tamaño de elementos en sus sprints de cualquier manera.

Re 2, si todavía está preocupado, primero debe idear algunas medidas para verificar si realmente hay algún error notable en sus planes de lanzamiento. Si es así, debe plantear el problema en la próxima retrospectiva para encontrar una solución junto con el equipo.

Alinear el valor de los puntos de la historia
RespuestasAquíPolítica de privacidad1y, 0v