¿Cómo pueden los puntos de la historia ser "no lineales" en tamaño relativo?

He leído en varios lugares que los puntos de la historia no son necesariamente lineales.

es decir, no es lo mismo una tarea de "8 puntos" que dos tareas de 4 puntos y así sucesivamente.

Entiendo totalmente el argumento de que estos son una indicación de complejidad en lugar de tiempo necesario.

Pero si no son una escala lineal, ¿cómo puedes hacer aritmética con ellos? Si un punto de historia de 8 toma, digamos, 3 veces más que 2 x 4 puntos de historia, entonces, ¿cómo funcionan los gráficos de evolución desde un punto de vista aritmético?

Si nuestra velocidad es, digamos, 30 por sprint, esto significa que podríamos hacer funciones de 30 x 1 punto de historia. Pero estos podrían ser, 30 trabajos de media hora. Del mismo modo, si se tratara de características de puntos de historia de 2 x 15, estas son probablemente tareas monstruosas que parecen igualmente improbables.

¿Quizás me equivoco al afirmar que no son lineales?

O alguien me puede explicar esto?

¡Gracias!

Le recomendaría que lea el libro de Mike Cohn sobre Historias de usuarios: mountaingoatsoftware.com/books/user-stories-applied . Esto le dará una buena comprensión de lo que representan las historias de usuarios y los puntos de la historia.
Te refieres a «historia de "8 puntos"».
Me temo que agregar números no lineales no permitiría usar adiciones para calcular el tamaño del sprint. No tendrá ningún sentido.

Respuestas (4)

Quizás una forma más precisa de decirlo sería que las estimaciones de los puntos de la historia son imprecisas. Si tiene un 5 y un 3, puede o no ser del mismo tamaño que un 8.

Para que esto sea menos confuso, comencemos con una escala no numérica como las tallas de camisetas. XS, S, M, L, XL y así sucesivamente. Podemos estar de acuerdo con bastante facilidad en que una camiseta pequeña y una camiseta mediana no te dan una camiseta grande. Sin embargo, una grande es más grande que una mediana y mucho más grande que una pequeña, y generalmente más pequeña que una XL. No siempre, por supuesto. Todos sabemos que una empresa en la que tenemos que comprar un tamaño diferente. Las historias de usuarios son de la misma manera. Es posible que tenga una M que en realidad sea más grande que una L, pero esta es la excepción, por lo que normalmente puedo suponer que una L es un paso más grande que una M.

Bien, ahora hagamos esto: XS-1, S-3, M-5, L-8, XL-13. Ahora, se aplican todas las mismas reglas. En algunos casos extremos, es posible que un 5 sea en realidad más grande que un 8, pero en términos generales, un 8 es un paso más grande que un 5.

Luego está el tema de la velocidad. Debido a que la relación entre los tamaños es generalmente consistente, podemos sumar los tamaños y, si trabajamos a un ritmo constante, tendremos un total bastante consistente. No será perfecto, tal vez 45 - 52, pero eso es lo suficientemente consistente como para ser útil para la planificación. Si tiene 35 puntos en el sprint, probablemente sea muy poco en este caso y 60 es casi seguro que es demasiado. Esta es también la razón por la cual la mayoría de los pronósticos son un rango, no una medida precisa.

DE ACUERDO. Creo entender. Pero en nuestros modelos mentales deberíamos apuntar a una escala lineal, ¿no? Quiero decir, sabemos que las cosas son imprecisas, pero en un mundo ideal serían perfectamente lineales. ¿Sería incorrecto que un equipo dijera "Creemos que un 8 es 3 veces más grande que un 5", por ejemplo?
Piénsalo en la otra dirección. Piense en ello como una escala no numérica. SML no son estrictamente lineales. Es más así. La única razón para usar números es que con suficientes puntos de datos se vuelve lo suficientemente consistente como para poder rastrear la velocidad. Tu equipo debe pensar que un 8 es dos pasos más grande que un 3, un paso más grande que un 5. No puedes dividirlos entre sí.
Lo entiendo. Simplemente no entiendo cómo puede hacer cosas como quemaduras o medir la velocidad si no son lineales Y asignables a un número. Digamos que el último sprint lo hice "5 x L, 3 x M y 6 x S". ¿Cómo puedo estimar mi velocidad cuando estoy haciendo el próximo sprint que consiste en "15 x M"? Es comparar manzanas y naranjas, ¿verdad?
@John, siempre comparará manzanas y naranjas porque (en términos generales) no hay dos tareas iguales. La idea detrás de los números es llegar a un "chequeo intuitivo" rápido. Daniel lo menciona al final: "lo suficientemente consistente como para ser útil para la planificación". No está tratando de hacer una declaración precisa "Definitivamente haremos 15 x M en el próximo sprint", está tratando de poner algo de ciencia y prueba detrás de la declaración "Podemos hacer 15 x M en el próximo sprint", es decir, "El equipo está estableciendo un hito alcanzable"
Esta es una de las cosas de las que se trata #noestimates. Una vez que su equipo tenga la experiencia suficiente, puede pasar a usar solo las tallas de las camisetas (que solo sirven como guía para ver si es necesario desglosar una historia, es decir, todo sobre un medio necesita dividirse). Esta excelente presentación de Allen Holub ilustra muy bien el punto, vale la pena verla youtube.com/watch?v=QVBlnCTu9Ms

TL;DR

Algunos sistemas de puntos de historia utilizan valores lineales, pero los profesionales ágiles experimentados rara vez utilizan estos sistemas, ya que los números suelen ser engañosos. Los sistemas no lineales exponen deliberadamente la imprecisión del proceso de estimación y se basan en funciones de suavizado para llegar a valores de planificación razonables para la capacidad del equipo.

Comprender los valores de esfuerzo relativo

En el uso común, lineal significa "secuencial". (NB: hay definiciones matemáticas y científicas que son más complejas). Sin embargo, la mayoría de los sistemas de señalización de historias no son secuenciales.

Podría decirse que el sistema de señalización de historias más común es la secuencia de Fibonacci modificada de Mike Cohn, donde cada valor es una función no lineal de los valores precedentes. La idea central es tener una historia de referencia igual a uno o dos puntos de la historia, y luego dimensionar todas las historias en relación con la historia de referencia.

El punto central de la historia es:

  1. La noción de que representan esfuerzo o complejidad, no tiempo.
  2. Un reconocimiento de que la estimación se vuelve menos precisa a medida que las historias se hacen más grandes.

Por lo tanto, una historia de 8 puntos está entre 4 y 8 veces el esfuerzo de la historia de referencia, y cae aproximadamente entre 5 y 13 en la escala de puntos. Cualquier intento de tratar una historia de 8 puntos como exactamente equivalente a ocho historias de un punto pierde un principio central del sistema, que es que las estimaciones son imprecisas por naturaleza y lo son aún más a medida que aumenta el tamaño (y, por lo tanto, el cono de incertidumbre) de la información. una historia aumenta.

Las métricas de puntos de historia como la velocidad pueden proporcionar un rango de valores para la capacidad esperada del equipo durante la planificación de Sprint, especialmente cuando se usa una función de suavizado como un promedio final. Intentar obtener una alta precisión de la métrica de velocidad o tratar los puntos de la historia como valores de tiempo lineales sería un mal uso de la metodología. Este es un antipatrón común, así que simplemente no lo hagas.

Nunca he oído hablar de esto. Los puntos de la historia son lineales (de lo contrario, sería imposible usarlos como una medida de velocidad). Sin embargo, la escala no es lineal, para evitar que la gente discuta si algo es un "5 o un 6": al usar una secuencia de pseudo-fibonacci, automáticamente se tiene en cuenta la vaguedad de la estimación.

Esto tiene más sentido para mí. Creo que tal vez la gente ha combinado la elección no lineal de números (el sistema de Fibonacci) con hacer que los números en sí mismos no sean lineales.
Para mí, como ocurre con la mayoría de las cosas en el mundo de la planificación de proyectos, los "puntos de la historia" y la "velocidad" son ideas útiles "hasta cierto punto", pero... "la realidad siempre se interpone". Por lo tanto, pienso en los puntos de la historia como "marcas que debes golpear". Prefiero seleccionar el número y la combinación de puntos que el equipo se esforzará por acertar y luego medir el porcentaje de puntos que realmente aciertan. Los puntos de la historia no son los mismos y, por lo tanto, solo son vagamente comparables. Por lo tanto, la "velocidad" variará naturalmente de un sprint a otro incluso cuando se "realiza" la misma "cantidad de trabajo".

Así que... esto es lo que solía enseñar cuando hablaba de Story Points en mis clases de CSM (ya no hablo de eso en mis CSM, a menos que me lo soliciten). Una estimación con puntos de historia lleva un "intervalo de confianza" a su alrededor, lo que significa su nivel de precisión. Y esa es LA razón por la que usamos los números de Fibonacci. Verá, podemos imaginar que la estimación es en realidad entre el número anterior y el número posterior. Cuanto mayor sea el número, menor será su precisión, porque el intervalo aumenta.

Recuerda la secuencia de Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21... ¿verdad? Entonces, una estimación de 3 puntos significa que creemos (implícitamente) que estará entre 1 y 5. Pero una estimación de 13 significa que creemos que estará entre 8 y 21. ¿Ves el intervalo más grande allí y, por lo tanto, la precisión más baja?

Por lo tanto, una historia de 13 puntos (implícitamente de 8 a 21) no necesariamente se dividirá en historias que sumen 13 puntos.

Otro factor es que, cuando el equipo divide una historia con una estimación mayor en historias más pequeñas, es porque han aprendido más al respecto. Podría, por ejemplo, significar que la incertidumbre en torno a cada uno de los cortes se ha reducido y, por lo tanto, también ha reducido la incertidumbre en torno al conjunto de historias cortadas juntas. O el equipo podría haber descubierto que hay algo más en lo que no habían pensado. Y eso, por supuesto, afectará la suma de las estimaciones.

Solo para aclarar, ¿ya no lo enseñas de esa manera o ya no enseñas CSM?
Ya no hablo de Story Points en mis CSM, a menos que se solicite. Gracias, lo acabo de editar. :)
Realmente nunca me han importado cosas como "Fibonacci" porque, francamente, "usar números y matemáticas" puede dar la impresión errónea de que las matemáticas son útiles y que las cosas que estamos contando son "contables". Siempre estoy nervioso por hacer proyecciones o informes a la gerencia que considero que pueden ser engañosos. O bien, eso podría arrojar al equipo bajo una luz innecesariamente mala.
ay, no me malinterpretes. Ni me importa Fibonacci... ni me importan las estimaciones. Simplemente lo cortamos muy fino y eso es lo suficientemente bueno. Cualquier cosa más que eso es pura suposición o, peor aún, BDUF. Solo espero que las personas que todavía usan estimaciones lo hagan de una manera menos dañina. Y, con el tiempo, evolucionar y soltarlo. Un paso a la vez. :)