¿Cómo asignar puntos de historia en historias de usuario extremadamente complejas?

Actualmente asignamos puntos de historia de la siguiente manera:

  • 0.5 muy simple (aproximadamente 0-30 minutos)
  • 1 simple (aproximadamente medio día)
  • 2 Dificultad media (un par de días)
  • 3 Duro (3 días)

Esto funciona bien para nosotros, aunque a veces, si estamos haciendo trabajo de infraestructura (integraciones, operaciones de desarrollo), no podemos usar la métrica anterior correctamente porque la tarea es demasiado grande. En ese momento, mi enfoque es tratar de dividir aún más la historia del usuario para que sea más fácil estimar su complejidad, pero luego descubrimos que no podemos, ya que la historia es la tarea.

¿Cómo aplica con precisión los puntos de la historia a tareas muy grandes? Gracias

"Tener más de 3 puntos" parece ser la respuesta trivial. ¿Hay alguna razón por la que limita sus estimaciones a 3 días como máximo en lugar de estimar la complejidad de una historia?
No equipare los puntos de la historia con las horas. Los puntos de la historia son una medida tanto del esfuerzo como de la complejidad y solo son relativos entre sí. No debe haber un mapeo de puntos a horas.
Medimos la complejidad en función del tiempo aproximado que llevará hacerlo en relación con otras historias. Dado que ejecuto sprints semanales, necesito tener una idea de cuánto tiempo tomarán las historias de los usuarios, de lo contrario, terminará en una situación de "cuánto tiempo dura un trozo de cadena".
@ThomasOwens están vagamente mapeados, una aproximación en el mejor de los casos. Si algo tarda más en implementarse, es justo decir que es más complejo que otras tareas para ese desarrollador en particular.
Se debe evitar cualquier mapeo. Además, el esfuerzo y la complejidad no están relacionados entre sí.
Realmente no entiendo cómo no lo son, si algo es muy complejo de implementar, generalmente llevará más tiempo implementarlo, ¿no? Obviamente, es subjetivo en lo que es complejo, por lo que debe basarse en el conjunto de habilidades del equipo.
@bobo2000 una historia compleja puede tener una solución sencilla. Y un CRUD simple, por ejemplo, puede ser complejo debido a la validación y restricción de entrada. En mi equipo, tuve que enseñar a otros miembros a evitar esta correlación.
Entonces, ¿cómo haces tu planificación de sprint para, por ejemplo, un sprint semanal, si no tienes ni idea de cuánto tiempo llevará completar las historias?
"¿Cómo se aplica con precisión ..." es donde te estás desviando. La estimación ágil pretende ser una aproximación "suficientemente buena", no "exacta" en el sentido de tener una precisión significativa.
Así es exactamente como lo estoy usando CodeGnome, "Medimos la complejidad en función del tiempo APROXIMADO (en relación con el esfuerzo)", segundo comentario sobre esta respuesta mía. Simplemente no puedo ver que esto funcione si no hace ningún mapeo, si le digo a mi parte interesada "bien, es complejo y no tengo idea de cuándo se hará", que es lo que otros sugieren, lo haré sentir inseguro y probablemente en algún momento me despidan por parecer que no tengo idea de cómo entregar el trabajo. Debe dar algún tipo de plazos aproximados en un rol de entrega. Del mismo modo, el equipo también debe saber esto.

Respuestas (3)

TL;DR

Mapear los puntos de la historia en el tiempo es un anti-patrón. Si debe hacer esto porque su entorno de trabajo lo requiere, entonces tiene trabajo que hacer para educar y evangelizar la agilidad en su lugar de trabajo. QED

Para tener éxito en la estimación ágil, asegúrese de que todo el equipo y las partes interesadas dentro de la organización estén de acuerdo en lo que realmente miden sus técnicas de estimación. Además, ¡asegúrese de verificar de forma rutinaria los resultados de sus técnicas de planificación para asegurarse de que se respete el cuadro de tiempo de iteración!

Los puntos de la historia miden el esfuerzo

Entonces, ¿qué miden los puntos de la historia? Miden el esfuerzo . En menor medida, también miden la complejidad, el riesgo y la incertidumbre en la medida en que esas cosas pueden influir en el esfuerzo, pero la métrica en sí solo se trata del nivel de esfuerzo involucrado en completar un entregable. Por ejemplo, en su publicación de blog "No equipare los puntos de la historia con las horas", Mike Cohn dice :

La complejidad influye en una estimación, pero solo en la medida en que la complejidad adicional afecta el esfuerzo involucrado en hacer el trabajo. Caminar hacia el edificio de un punto mientras se canta "Gangnam Style" es probablemente más complejo que caminar hasta allí sin cantar. Pero la complejidad adicional de cantar no afectará la cantidad de tiempo que me lleve caminar hasta allí, por lo que mi estimación en este caso seguiría siendo una.

Si solo está siguiendo los movimientos de tratar el tamaño relativo como una estimación de nivel de esfuerzo no anclada, entonces deje de hacerlo y solo mida el tiempo directamente. No serás más preciso en tus actividades de planificación, y de hecho puede que lo seas menos, pero al menos no frustrarás a todos llamando a un peine "dinglehopper" como lo hace la Princesa Ariel en La Sirenita .

Medir el tiempo con límites

Incluso Mike Cohn admite que los puntos de la historia miden el tiempo indirectamente , pero solo indirectamente. Eso es porque en marcos ágiles como Scrum, realmente solo nos preocupamos por dos límites de tiempo:

  1. El standup diario. Nos importa si las tareas coordinadas van por buen camino o no, y podemos usar la regla general de 1 o 2 días para las tareas a fin de determinar si una historia va por buen camino o está en riesgo. Sin embargo, el cuadro de tiempo de standup-to-standup es un control de proceso, no una medida de velocidad o un punto de referencia para la precisión del equipo.

  2. El Sprint o tamaño de iteración. En el análisis final, todo lo que importa es si se puede cumplir el Sprint Goal. Si el objetivo no se puede cumplir dentro del plazo, entonces el nivel de esfuerzo superó la capacidad del equipo y el trabajo no se planeó correctamente.

La única medida esencial de tiempo dentro de Scrum es si el trabajo planificado se realiza o no al final del Sprint. Idealmente, usa su velocidad para asegurarse de que el equipo no asuma más trabajo del que se puede hacer en un solo Sprint y para planificar el lanzamiento, pero estas medidas se refieren a la capacidad de trabajo por Sprint, no directamente al tiempo.

Scrum se trata de usar pronósticos de la capacidad del equipo para administrar el alcance del trabajo para que se ajuste a plazos predecibles. No se trata de estimaciones de tiempo de nivel de tarea altamente precisas, o de azotar al equipo para que trabaje más duro o más rápido. ¡La clave es desarrollar una cadencia predecible!

Cargas de trabajo de verificación de cordura usando límites de Sprint

Está bien, finge por un minuto que en realidad estás bebiendo Kool-Aid. Eso significa que usted acepta a priori lo siguiente :

  • Los puntos de historia producen mejores estimaciones de capacidad por Sprint que medir "con precisión" el tiempo de la tarea.
  • Determinar el alcance del trabajo para que se ajuste a la capacidad del equipo produce una cadencia sostenible que tiene éxito aproximadamente el 80 % de las veces.
  • Medir el éxito por las metas cumplidas en lugar del número de tareas realizadas es la medida del éxito de la organización.

Dado todo eso, ¿cómo validas tu tallaje relativo? De nuevo, volvemos a la unidad clave de medida del tiempo en Scrum: el Sprint.

Los puntos de historia son realmente solo un valor intermedio para estimar la capacidad. Funcionan bien, pero existen otras técnicas de estimación. Uno de mis favoritos es TFB/NFC/1, que es un sistema en el que determinas si una historia o un conjunto de historias:

  • cabe en un solo Sprint (1)
  • es demasiado grande para caber en un solo Sprint y debe descomponerse o refactorizarse (TFB)
  • no se puede estimar tal cual o con el conocimiento actual del equipo (NFC)

También puede usar este tipo de técnica junto con los puntos tradicionales de la historia. Al observar el Sprint Backlog como una gestalt y determinar si todo el libro de trabajo se puede hacer de manera confiable dentro de un solo Sprint, ¡genial! Si su otro proceso de estimación produce un retraso que resulta en una verificación instintiva de "demasiado grande" para un solo Sprint, o (peor aún) "sin ni idea", entonces debe revisar el plan hasta la meta planificada y asociado el trabajo encaja dentro de un solo Sprint.

Ya sea que use TFB/NFC/1, una verificación intuitiva u otra técnica de estimación, no es lo importante. Su estrategia clave es asegurarse de que el equipo (y el resto de la organización) respete la caja de tiempo. Planifique solo el trabajo suficiente para adaptarse a la iteración y refine continuamente su proceso de planificación y estimación hasta que pueda hacerlo de manera confiable la mayor parte del tiempo. ¡Esa es la esencia de la planificación ágil!

+1 para el concepto "TFB/NFC/1". ¡No lo sabía y parece bastante útil!

Estoy tratando de responder a esto y teniendo en cuenta los comentarios anteriores.

Asignación de punto a tiempo de la historia

Entiendo el deseo de asignar la complejidad (puntos de la historia) al tiempo/dinero (horas/dólares), pero como dice Jeff Sutherland :

Los puntos de la historia brindan estimaciones más precisas, reducen drásticamente el tiempo de planificación, predicen con mayor precisión las fechas de lanzamiento y ayudan a los equipos a mejorar el rendimiento. Las horas dan peores estimaciones, introducen grandes cantidades de desperdicio en el sistema, perjudican la planificación de lanzamiento del propietario del producto y confunden al equipo sobre qué mejoras de proceso realmente funcionaron.

Lo que significa que las estimaciones de tiempo son en su mayoría incorrectas y te dan una falsa sensación de seguridad. Como menciona @vander-lauriano-da-silva, hay tareas que son muy complejas (de alguna manera lo has pensado mucho y son difíciles de implementar) pero pueden hacerse en poco tiempo Y hay tareas que son realmente simples, pero lleva mucho tiempo implementarlo. Entonces el mapeo es peligroso (@ThomasOwens). La complejidad aproximada debe ser "suficientemente buena" para trabajar con (@codegnome).

¿Qué hay por encima de 3SP (Difícil)?

Si insiste en mapear, no veo ningún problema en usar 5SP (Very Hard), como también mencionó @nvoigt. ¡Pero esto debería ser algo que se pueda hacer en 5 días (= 1 semana = duración del sprint)!

Historias divididas

Tal vez reconsidere la forma en que corta sus historias, para asegurarse de que la historia NO sea la tarea . Según mi experiencia, las Historias de más de 3 pueden dividirse en su mayoría de alguna manera (por supuesto, eso depende de un equipo a otro).

Hay varias fuentes de cómo hacer esto:

Otras formas de dividir

Si su historia es demasiado grande, también puede convertirla en una épica y agregarle historias. Es posible que eso no resuelva su problema en primer lugar, pero tiene Historias que encajan en un sprint, sin perder el contexto de la función.

Duración del sprint

También puedes pensar en la duración del sprint, ¿por qué tiene que ser de 1 semana? La mayoría de los equipos que conozco funcionan bien con 2 semanas (también reduce el número de planificaciones, revisiones y retrospectivas).

"Entonces, ¿cómo haces tu planificación de sprint para, por ejemplo, un sprint semanal?"

Echo un vistazo a la velocidad (puntos de historia / sprint) de los últimos 3 sprints y estimo cuántos puntos de historia se pueden "quemar" en el siguiente

Trabajo de infraestructura / DevOp

Tal vez estos enlaces también puedan ayudar:

Eso es lo que he dicho, mi mapeo es una aproximación 'suficientemente buena' basada en el conjunto de habilidades del equipo que realiza un trabajo similar. Estoy de acuerdo en que tratar de dedicar tiempo a una tarea es ridículo y nunca funciona, ya que las tareas de software requieren investigación, implementación, prueba. ¿Cómo se mide el tiempo de investigación? Pero si está tratando con partes interesadas, necesita hacer un mapeo, mi CEO me preguntará aproximadamente cuánto tiempo llevará entregar x cosa, ya que necesita transmitir esa información a los clientes potenciales para las ventas. Si digo, 'No sé, pero la complejidad es 3', no va a funcionar.
Creo que este es uno de los puntos más importantes para el debate entre scrum y gente de negocios. Yo diría: "la complejidad de este 3SP y si nuestra velocidad se mantiene estable y la priorizamos por encima de nuestra cartera de pedidos, se puede completar aproximadamente en el próximo sprint". - sabiendo que esta no es una respuesta totalmente satisfactoria. Pero si dice: "Esta tarea tomará 3 días" pero necesita 5 o más días al final, habrá más frustración en el lado comercial, ya que podrían tomar esta declaración como un hecho.
Parece que estamos en la misma página... Cuando trato con mi parte interesada, normalmente le digo que tomará una cantidad x de sprints en relación con la complejidad de la tarea. Pero no puedo decir que tomará 1 sprint en lugar de 2 (7 o 14 días respectivamente) si no estoy seguro de que 5 o 14 días reflejen la cantidad de esfuerzo necesario para realizar mi tarea. Es más difícil evaluar esto cuando se trabaja en tareas de operaciones de desarrollo o infraestructura que, por ejemplo, una función menos compleja que usa Javascript por experiencia.
Entonces, la clave es que, para tareas normales (bien conocidas), su forma de estimar funciona bien. Su problema son las tareas de operaciones de desarrollo que generalmente no se realizan y tienen mucha incertidumbre. ¿Podría dar algunos ejemplos a qué tareas se refiere y qué sucedió en el pasado?
Básicamente, sí, un buen ejemplo es ahora mismo, donde la tarea es agregar un servidor de producción adicional a la pila. Tenemos que crear un script de pila para hacer esto, pero eso solo toma 2 sprints. No sé cuántos puntos asignarle, y no se puede desglosar más. Es literalmente una tarea.
Como esto parece no ser necesario, una tarea real de desarrollador de equipo debe realizarse dentro del equipo. Consideraría obtener ayuda externa para eso (no conozco su empresa, pero tenemos expertos dedicados a esas cosas).
Actualmente tenemos el conjunto de habilidades dentro del equipo para hacerlo, la confusión es no saber cuántos puntos de historia asignarle. Si le doy un valor arbitrario, los puntos de la historia pierden sentido.

Solo un pensamiento si alguien quiere construirlo ... Mediana de horas * multiplicador de rango de probabilidad de escala inversa N hr con desviación promedio d / d (no estándar). Al ingresar N y da, la calculadora de rango lo escribirá en inglés para su confirmación. Donde d es el rango de distribución la mitad del tiempo porque la mitad es la más simple. por ejemplo, 1 hora * 3/3 (3 horas a 20 minutos, normalmente 1 hora) o 1 hora * 1,5/1,5 (1,5 horas a 40 minutos, mediana 1) Luego dé a los postores más bajos la primera opción para demostrar que su estimación es correcta delegando la tarea. Por lo tanto, el delegante, no el ejecutante, es el juzgado. La mayoría delegará en ellos mismos o en aquellos en quienes confían. Esto requerirá la programación de socios para compartir habilidades. Cualquiera que se niegue a hacer una tarea debe decirlo antes de dar estimaciones. Una distribución gamma es una distribución de probabilidad de máxima entropía con un parámetro de tasa de escala inversa. La complejidad distribuye la entropía. Por lo tanto, deben adivinar la mediana (no el promedio) y la desviación de probabilidad de escala inversa (no +/- tiempo). Luego, esto se somete a una prueba de chi cuadrado en ensayos repetidos para determinar la precisión que puede retroalimentarse como un multiplicador de precisión de tendencia. Esto también proporciona gráficos de quemado más precisos, ya que la variación pronosticada se puede mostrar y también quemar. El progreso de chi cuadrado individual (el tiempo previsto menos el tiempo real, elevado al cuadrado y luego dividido por el tiempo real) también se puede medir, ya que la experiencia tenderá a ser una norma. Luego, esto se somete a una prueba de chi cuadrado en ensayos repetidos para determinar la precisión que puede retroalimentarse como un multiplicador de precisión de tendencia. Esto también proporciona gráficos de quemado más precisos, ya que la variación pronosticada se puede mostrar y también quemar. El progreso de chi cuadrado individual (el tiempo previsto menos el tiempo real, elevado al cuadrado y luego dividido por el tiempo real) también se puede medir, ya que la experiencia tenderá a ser una norma. Luego, esto se somete a una prueba de chi cuadrado en ensayos repetidos para determinar la precisión que puede retroalimentarse como un multiplicador de precisión de tendencia. Esto también proporciona gráficos de quemado más precisos, ya que la variación pronosticada se puede mostrar y también quemar. El progreso de chi cuadrado individual (el tiempo previsto menos el tiempo real, elevado al cuadrado y luego dividido por el tiempo real) también se puede medir, ya que la experiencia tenderá a ser una norma.https://en.wikipedia.org/wiki/Gamma_distribution#Median_calculation

¿Cómo asignar puntos de historia en historias de usuario extremadamente complejas?
RespuestasAquíPolítica de privacidad1y, 3v