¿Por qué usamos puntos de historia en lugar de días de hombres cuando estimamos historias de usuarios?

En metodologías ágiles (p. Ej. SCRUM), la complejidad / esfuerzo necesario para las historias de los usuarios se mide en puntos Story. Los puntos de historia se usan para calcular cuántas historias de usuario puede tomar un equipo en una iteración.

¿Cuál es la ventaja de introducir un concepto abstracto (puntos de la historia), donde podemos usar una medición concreta, como los días hombre estimados? También podemos calcular la velocidad, estimar la cobertura de una iteración, etc. usando días-hombre estimados.

En contraste, los puntos de la historia son más difíciles de usar (porque el concepto es abstracto) y también más difíciles de explicar a los interesados. ¿Qué ventaja ofrece?

Creo que una de las principales ventajas es que los humanos y los desarrolladores específicamente son bastante malos para estimar el tiempo. Piense también en la naturaleza del desarrollo: no es una progresión lineal de principio a fin. A menudo es "escribir el 90% del código en 10 minutos y luego arrancarte la depuración durante 17 horas". Eso es bastante difícil de estimar en el sentido del tiempo del reloj.

Pero el uso de una abstracción elimina el enfoque del tiempo real en horas o días y, en cambio, se enfoca en describir el gasto relativo y la complejidad de una tarea en comparación con otras tareas. Los humanos / desarrolladores son mejores en eso. Y luego, una vez que empiece a tararear con esas estimaciones puntuales y algún progreso real, puede comenzar a mirar el tiempo de manera más empírica.

Sospecho que también hay un efecto observador que ocurre con las estimaciones de tiempo que no sucederían con las estimaciones puntuales. Por ejemplo, el incentivo para hacer una estimación de la bolsa de arena y entregarlo "antes de lo previsto" se silenciará con la indirección en un sistema basado en puntos.

Si usa números de Fibonacci (o algo similar), limita el número de opciones al estimar una historia. Trabajé con un grupo que solo usaba números bajos: 1, 2, 3, 5, 8 y 13. Teníamos una historia de referencia que era un 5. Esto nos permitió tomar decisiones rápidas sobre la complejidad de una historia mientras hacía Planning Poker . El otro efecto secundario fue que cualquier cosa calificada como 13 probablemente tenía información insuficiente y necesitaba ser desglosada aún más. Dudo seriamente que hubiera sido tan fácil y sencillo si estuviéramos usando horas crudas.

El propietario de su producto habla el idioma de sus partes interesadas y debería poder traducir entre puntos de historia y horas de trabajo (u otras unidades) según sea necesario. Durante mi tiempo como OP, tuve algunos datos sólidos de que 1 punto de historia = 4 horas-hombre, pero obviamente cada equipo es diferente.

Editar:

Con el conocimiento de que 1 punto = 4 horas, teóricamente podrías cambiar tu mazo de Planning Poker a 4, 8, 12, 20, 32 y 52. ​​Pero esos números se sienten más difíciles de manejar. Creo que mentalmente abstraería los valores de regreso a algo simple, por ejemplo, "menos de un día", "más de una semana", etc. Y si voy a hacer eso, también podría seguir con la unidad abstracta sin puntos de historia.

Es para permitir que la estimación mejore con el tiempo, sin que todos los estimadores tengan que ajustar su estimación.

En lugar de que todos los involucrados en la estimación tengan que pensar como "OK ... parece 2 días hombre ... pero el último sprint subestimamos todo, así que tal vez sean realmente 2,5 días hombre. ¿O 3?", Continúan igual que siempre. "¡5 puntos de historia!"

Luego, ajusta su estimación de cuántos puntos de historia puede superar el equipo en un sprint, en función del logro real medido en sprints anteriores. "¡Hemos estado haciendo 90-110 puntos de historia por sprint anteriormente!"

Diría que la teoría detrás de esto es que los desarrolladores son mejores para estimar la complejidad relativa de diferentes tareas de desarrollo que para estimar los absolutos . Especialmente si varias personas están estimando una tarea que podría realizar cualquiera de ellos (y no todos trabajan a la misma velocidad que los demás).

Alternativa cínica: lo he visto decir que los desarrolladores nunca llegan bajo estimaciones de tiempo. Si algo lleva más tiempo de lo estimado, te habrás ido. Pero si algo lleva menos tiempo de lo estimado, los desarrolladores pueden jugar con él, dorar, o simplemente reducir la velocidad y tomarlo con calma ya que se les ha asignado una tarea cómoda. Tomar las unidades de tiempo reales de una estimación puede frenar estas tendencias. Fin de la alternativa cínica.

Los días del hombre o las horas del hombre son, como usted dice, concretos. Entonces, cuando una tarea se estima en 5 horas y toma 6, ahora es una tarea tardía.

Cuando tienes una historia que tiene 3 puntos y lleva 6 horas, tomó 6 horas, no es tarde, solo tomó seis horas. La medición de la velocidad es más un factor de cuántos de esos puntos se hacen en un sprint, y ese número puede fluctuar, porque no es concreto. Tampoco está midiendo cada tarea, sino el total de todas las tareas. Cuando tienes horas en cada tarea, la tentación está ahí para medir cada tarea. Cuando eso sucede, no obtienes ningún beneficio para el sprint por terminar con el tiempo y es una consecuencia por terminar con el tiempo de una tarea determinada.

Puede ser una transición al pensamiento en términos de puntos. Trabajé en un lugar antes de que incluso introdujiéramos camisetas ágiles usadas solo para tener una idea del nivel de esfuerzo. Los puntos son solo una extensión de eso.

Eso no quiere decir que no haya controversia, o alguna asignación arbitraria a los puntos. Tenemos miembros de nuestro equipo que casi siempre votan el número más bajo y se quejan cuando piensan que una tarea es un 1 y creemos que es un 3 que estamos sufriendo de inflación puntual.

La abstracción es una especie de punto. Usar el 'día del hombre' como medida tiene una serie de dificultades, que incluyen:

1. Si el equipo no está familiarizado con la tecnología que van a utilizar, puede ser muy difícil dar estimaciones en tiempo real de cuánto tiempo puede llevar una tarea. Es mucho más probable que puedan dar buenas estimaciones relativas, por ejemplo, "la tarea A probablemente tomará el doble de tiempo que la tarea B".
2. ¡Diferentes personas trabajan a ritmos diferentes! Si usa 'días hombre', prácticamente tiene que cambiar el tiempo estimado cuando se pasa una tarea de un desarrollador a otro. ¿Quién define cuánto trabajo constituye un 'día del hombre' de todos modos?

Si desea estimar días-hombre, es un cálculo simple:

user points in story / average user points per developer per day = estimated man days

Como ya se mencionó, los puntos de la historia son una medida relativa de complejidad. Se puede usar la potencia de 2 series (1,2,4,8,16 ...) o una escala de Fibonacci (1,2,3,5,8,13,20 ...) para la estimación. Como los desarrolladores propuestos son bastante expertos en decir algo como esto:

La función A es casi dos veces más difícil que la función B

Pero es realmente difícil decir "cuánto tiempo" llevará esta característica para su implementación. Dejas que eso sea equilibrado por la velocidad. Entonces, si algo se estimó como un 5 pero resultó ser un 13, una velocidad más lenta normalizaría eso para la iteración (o podría volver a estimar).

Ahora, hay otra alternativa, se llama 'días ideales' (algo similar a los días hombre pero no estoy seguro de si eso es lo que querías decir) y sé de algunos equipos que prefieren eso. Los días ideales deben interpretarse como:

Si eso es todo lo que hago después de llegar a la oficina y tomar solo los descansos necesarios, no tengo interrupciones y tendré todo lo que necesito para 'implementar la historia', es decir, no actividades periféricas como reuniones, responder correos electrónicos, etc.

Mike Cohn, uno de los muchos evangelistas ágiles bien conocidos, ofrece la siguiente comparación entre los puntos de la historia y los días ideales.

Puntos de historia

• Ayuda a impulsar el comportamiento interfuncional, es decir, los equipos estiman historias con una complejidad de implementación total desde la interfaz de usuario hasta la base de datos y viceversa.
• Las estimaciones de SP no decaen, es decir, dentro de unos meses, es probable que una historia de 5 puntos sea de 5 puntos, pero una estimación del día ideal puede cambiar dependiendo de la habilidad / velocidad de desarrollo adquirida de ese programador en particular
• Los SP son una medida pura del tamaño, es decir, solo reflejan el tamaño y la complejidad del wrt. Período. Sin duración, etc., tirarlo. Ese es el trabajo de la velocidad. Pero no es así con los días ideales. De hecho, con los días ideales hay una tendencia a confundirlo con los días calendario. Manteniéndolo abstracto como SP lucha contra la tentación de comparar con la realidad. Solo una medida de tamaño. Sin tonterías.
• Es típicamente más rápido que los días ideales. Puede ser complicado para el primer par de historias, pero una vez que te acostumbras, es más rápido.
• Los diferentes desarrolladores pueden tener una opinión diferente sobre su estimación de día ideal para completar una historia. Yo podría hacer lo mismo en 3 y tú en 5. Los SP son más o menos uniformes en todos los ámbitos. Nivelan el campo de juego, por así decirlo.

Días ideales

• Más fácil de explicar fuera del equipo; por obvias razones :)
• Más fácil de estimar al principio como se mencionó anteriormente. Pero una vez que te acostumbras a los SP, es algo natural

Ahora, cuál elegir depende del equipo. Sin embargo, como la mayoría de las respuestas aquí y mi experiencia personal, prefiero los puntos de la historia. Los días ideales realmente no tienen tanto beneficio sobre los SP (y Mike Cohn también aboga por SP junto con muchos otros evangelistas ágiles).

Los puntos de historia también lo ayudan a medir la mejora del rendimiento del equipo con el tiempo. Además, no necesita volver a estimar todo a medida que mejora el rendimiento.

Tome este ejemplo que usa días hombre:

El equipo estima diferentes tareas con días-hombre. Funciona por un tiempo, pero después de un tiempo ves que el equipo se hace más rápido con muchas tareas de lo que originalmente se pensaba. Entonces el equipo vuelve a estimar las tareas. Funciona por un tiempo, y después de un tiempo vuelves a ver lo mismo: el equipo se hace más rápido con muchas tareas nuevamente. Entonces vuelves a estimar nuevamente, y esta historia se repite una y otra vez ...

¿Por qué? Porque el rendimiento de su equipo aumentó. Pero no lo sabes.

El mismo ejemplo con puntos de historia:

El equipo estima el tamaño de las historias de los usuarios. Después de algunos sprints, ves que el equipo puede hacer alrededor de 60 puntos de historia por sprint. Más tarde, verá que el equipo ha logrado más de 60 puntos de historia, tal vez 70. Y el equipo continúa así y saca más historias de usuarios para los próximos sprints y los entrega.

¿Por qué? Porque el rendimiento ha aumentado. Y puedes medirlo. Y no necesita volver a estimar todo después de que el rendimiento de su equipo haya aumentado.

Primero, las personas son mejores en estimaciones relativas que en estimaciones absolutas. El mapeo de los babilonios y la calificación del brillo relativo de las estrellas es un gran ejemplo. No obtuvieron las cifras absolutas correctas, pero el orden fue mayoritario incluso para intensidades muy similares.

La segunda ventaja es que una razón principal para hacer este ejercicio es impulsar la conversación. Si comienza a discutir en días exactos, la conversación puede descarrilarse rápidamente.

Como dijo Napoleón: el plan no tiene valor, la planificación es invaluable.

En tercer lugar, el gerente del proyecto no tiene que editar todas las estimaciones, solo porque resulta que las estimaciones estaban apagadas por un factor de, por ejemplo, 130%.

Los Story Points reflejan la complejidad del problema y, por lo tanto, reflejan la confianza (o riesgo) de cuán precisa es la estimación.

Una historia con un punto de historia alto me dice que están sucediendo muchas cosas con la historia del usuario que no es concreta.

La idea es ver cuál es un buen equilibrio entre los diferentes puntos de la historia. Si se me muestra un plan de iteración con historias con todos los puntos importantes de la historia, esto me da poca confianza en que la iteración se ejecutará como se esperaba y que necesitamos ver otras historias para la iteración o comenzar a desglosar las historias.

Cuando se comunica con un gerente o propietario del producto, los puntos importantes de la historia significan que será extremadamente confuso cuándo obtendrán una característica particular. Una de las soluciones a esto es desglosar la historia y, con suerte, tendrá una combinación de puntos de historia bajos y altos con los que trabajar para que pueda demostrar de manera iterativa el progreso al propietario del producto.

Los días del hombre estiman el tiempo que lleva hacer algo. Se utilizan mejor cuando los elementos que está estimando son muy precisos y medibles. Las tareas específicas, bien conocidas y repetibles son estimables en días humanos.

Por ejemplo, si una persona de ventas puede hacer 20 llamadas de clientes por día, en promedio, podemos calcular cuánto tiempo toma cada llamada y a partir de eso podemos estimar cuántos días hombre tomará hacer 1000 llamadas.

En este ejemplo, se puede pensar concretamente en términos estadísticos acerca de la duración media de una llamada porque se puede suponer que todas las llamadas son efectivamente la misma cosa.

Los puntos de historia determinan qué combinación de historias se puede hacer en una iteración. Se utilizan para combinar objetivos heterogéneos con límites difusos y para medir cuántos se pueden hacer en un marco de tiempo fijo. Estiman la complejidad de los fragmentos de trabajo comparados entre sí para poder sumarlos.

Por ejemplo, su equipo desarrolló 5 historias para un total de 23 puntos en la iteración 1, y 8 historias para 20 puntos en la iteración 2. A partir de esto, puede estimar que en la iteración dos su equipo hará algunas historias cuyo total es de alrededor de 20 puntos en iteración 3.

Tenga en cuenta que no necesitamos determinar el tamaño de un punto y, en particular, ¡no se asume que cada historia del mismo tamaño llevará el mismo tiempo para desarrollarse! Solo trabajamos con sumas y puntos por iteración. Ni siquiera mencioné cuánto dura la iteración.

Si caminas hacia un humano en la calle y le preguntas "¿Qué tan grande era un T-rex?" las respuestas fluctuarían aunque la mayoría de los humanos sepan qué es un T-rex, qué tan grande era, pero nadie lo sabe con certeza, porque NO tenemos una escala relativa desde la línea de base.

Ese es el comportamiento cognitivo que estás tratando de descubrir con el pronóstico y muchas metodologías giran ciclos con "¡ Lo tengo! .. ¡Tengo el secreto para un pronóstico preciso! ", El aceite de serpiente para las masas. Cuando realmente pronosticas, estás diciendo en voz alta " PERMITIRÉ x días / horas / puntos para que eso se complete ", es en cierto sentido crear una "caja de tiempo" para que ese evento se lleve a cabo dentro.

Para mí, Points solo está cambiando los límites, al final del día, a menos que estés en un equipo que esté feliz de decir " * Bueno, tenemos 3 semanas por sprint y chupa el pulgar ... Supongo que deberíamos disparar por ¡30 puntos para completar en ese ciclo! ¡Quién está conmigo! * "Y eso es lo más profundo que puede llegar en el modelado de pronósticos, ¡bien! ..asisticamente, solo estás estableciendo un presupuesto arbitrario y eso es todo. También estás en retrospectiva mirando el trabajo completado con una sensación de "mierda sagrada, hicimos 33 puntos que corrieron, eso fue bastante bueno" y no se puede hacer mucho al respecto. Puede usar la velocidad para determinar la mitad del sprint que está recibiendo su inversión de presupuesto preguntando en voz alta " ¿Ya hemos alcanzado los 15 puntos? ¿Lo haremos?""pero el peligro aquí es que ahora estás usando Velocity para medir la productividad, no la capacidad, que por lo que entiendo patea la gestión de liberación reactiva (puntos de historia) en la cabeza ...

El sistema de puntos es casi demasiado inteligente como para no darse cuenta de que todavía le asigna un tiempo relativo a la ecuación, todo, desde sus "ciclos de sprint" acordados hasta sus paradas diarias en las que promulga alguna regla oculta sobre la duración + complejidad = " Max se está demorando demasiado con esa tarea "instinto innato código del equipo momento rojo?

El cerebro humano no puede pronosticar porque implica una gran cantidad de memoria de trabajo mezclada con un recuerdo a largo / corto plazo, por lo que es como pedirle a un estudiante de matemáticas novato que haga fracciones en su cabeza, no en papel ... Es por eso que otras industrias nunca acuerdan un pronóstico y validar constantemente los pronósticos en un tiempo relativo (por ejemplo, el geólogo nunca detiene el modelado de pronósticos hasta que ese metro cúbico haya sido excavado del suelo y luego esté "listo").

Yo diría que el sistema de puntos funciona si no estás pronosticando . Estás de acuerdo con una gran parte del trabajo que se basa en un algoritmo de sub-fragmentación, pero ese es realmente tu enfoque más cercano a la predicción como sea posible. De hecho, la administración de su versión buscaría interrupciones naturales en la cola de "trabajos pendientes" que se ajustan a los temas (es decir, en Silverlight, los gerentes de producto esperaríamos hasta después de completar su trabajo atrasado y juntar los temas que establecimos inicialmente. nunca supimos lo que el equipo de ingeniería estaba haciendo específicamente, solo teníamos un esquema básico. Luego tomábamos ese cuerpo de trabajo y construíamos nuestro evento de marketing en torno a él (Microsoft Mix))

Cuando comienzas a bloquear las expectativas de velocidad dentro de los ciclos de sprint que dependen de la velocidad + el tiempo, vuelves a pronosticar las estimaciones nuevamente solo que esta vez estás peor porque estás jugando el juego "depende" ... Más importante aún También está matando el potencial para el crecimiento del equipo / crecimiento profesional también.

El impuesto que paga por Puntos vs Tiempo es con los puntos que necesita para buscar fórmulas de medición alternativas para rastrear el desarrollo / mentoría de habilidades laborales o el comportamiento del desarrollador.

Como aún necesitará mirar a un "desarrollador mediano" como su persona ideal para unir habilidades / esfuerzos, puede poner en línea a otros desarrolladores con esa persona para determinar cómo se desenvuelven en su crecimiento continuo dentro de su equipo. También destaca situaciones en las que los desarrolladores "rápidos" llevan la mayor parte del agua, pero se están aburriendo o peor, están trabajando más horas y no hay reconocimiento / recompensa debido a plazos competitivos, etc. allí para detectar malos olores dentro del equipo por decir, como en "esa persona está luchando, vamos a ayudar"

A continuación también vienen las historias de "arrastre", historias que no se agrupan en ese ciclo de sprint pero luego se extienden al siguiente ciclo de sprint. Lo que luego puede crear fácilmente un efecto indirecto si está factorizando en el tiempo, pero en el momento en que sí tiene en cuenta el tiempo relativo ... nuevamente, simplemente regresó a "pronóstico / estimación basado en el tiempo" y nuevamente el sistema de puntos es solo enturbiando las aguas.

Si vas a puntos, ignoras el tiempo por completo y me refiero completamente al momento en que dejas pasar el tiempo, estás jugando con la idea / metodología.

Después de haber viajado por todo el mundo como evangelista, vi que muchos equipos juraban lo que querían que habían descifrado el código del Pronóstico Ágil ... pero siempre hacía clic en mi lengua, sonreía y me alejaba con el pensamiento " sí ... casi lo hiciste, pero esa amante que llamamos 'tiempo' ... ella es cruel ... "

El libro de Mike Cohn "Estimación y planificación ágiles" describe las ventajas y desventajas de estimar con "días ideales" o puntos de historia, por lo que la respuesta rápida a su pregunta es que no tiene que estimar con puntos de historia. Si es más natural estimar en días ideales, adelante.

Creo que el método Story Point tiene al menos dos ventajas importantes sobre el método del día del hombre: Primero, es más fácil de estimar en SP. SP es relativo y los humanos como nosotros son mejores en estimación relativa que absoluta como el método del día del hombre.

En segundo lugar, cuando calcula en SP, obtiene "Team SP" y no "Individual Manday". Cuando preguntas "¿Cuánto tiempo llevará esta tarea?", El desarrollador Senior puede darte 1 día pero 5 días para un Junior. Ese es Man-Day depende de quién llevará a cabo esa tarea. Si el propietario se ve obligado a cambiar (¡y lo hará!), Debe volver a programar todo. Con SP, sigue siendo el mismo quien toma la tarea.

Me sorprende que nadie haya mencionado la Ley de Parkinson todavía.

El trabajo se expande para llenar el tiempo disponible para su finalización.

Básicamente, si está estimando en cualquier tipo de unidad de tiempo para tareas grandes, los desarrolladores tenderán a tomarse el tiempo que estimaron para completarlo o repasarlo. Cuando calcula en un tiempo nebuloso como Story Points o Shirt Sizes, evita esta trampa.

La estimación del punto de la historia sigue la serie de Fibonacci 1,2,3,5,8,13,21 ...

Un cerebro humano puede mapear fácilmente cosas en función de los tamaños. Por ejemplo: tenemos una tarjeta postal y le asignamos un punto de historia 2 y tres el tamaño de la tarjeta significaría 2 * 3 = 6 puntos de historia.

Story Point 6 se encuentra entre las series de Fibonacci número 5 y 8, siendo 5 el número más cercano y, por lo tanto, el punto de la historia sería 5.