¿Cómo debe manejar un equipo los desacuerdos sobre las estimaciones de puntos de historia en Scrum?

Durante la estimación, el Product Owner presenta una historia de usuario que parece clara para un equipo que generalmente conoce sus fortalezas y debilidades, y que no es hostil. ¿Qué debe hacer el Scrum Master si los miembros del equipo juzgan la historia de manera muy diferente, pero no pueden convencerse entre sí lo suficiente como para acordar una estimación de puntos de la historia?

Por ejemplo, digamos que surgen dos opiniones. Algunos ven esto como una historia bastante fácil (por ejemplo, 2 puntos) y otros prevén complicaciones técnicas y juzgan que la historia debería ser de 20 puntos. Los votantes de 2 puntos dicen: "Entiendo su opinión, pero no creo que esas complicaciones sean válidas". Los votantes de 20 puntos dicen: "El pasado nos dice que estas cosas siempre son mucho más complicadas de lo que parecen".

Supongo que si el problema no se aclara, la facción de 20 puntos no se comprometerá con la historia del usuario si (en su opinión) está subestimada.

¿Qué debe hacer el Scrum Master en este caso? Ir por el promedio? ¿Elegir el peor de los casos? ¿O aceptar esta historia de usuario como de "alto riesgo" con solo un compromiso parcial durante la planificación del Sprint?

Me gustaría señalar que este no es un problema exclusivo de Scrum. Los desacuerdos sobre la dificultad de implementación pueden ser un tema difícil bajo cualquier metodología.
Por lo general, resolvimos esto dándole la historia a la persona que dijo que podía hacerlo por 2 puntos.
Arquitectar la solución. Si los dos punteros persisten, asígnelos.
@aclear16 El Scrum Master no asigna trabajo a miembros individuales del equipo. El Scrum Master exitoso entrena al equipo para que se organice a sí mismo.
Por supuesto. No dices que se lo estás asignando a ellos. Los desafías a probar su solución. O guía al equipo a elegirlos. O lo que sea. Es el mismo efecto. Todos se obsesionan demasiado con las reglas y las cosas no se hacen. Es lo mismo que atascarse demasiado con la documentación y los requisitos en cascada. Cumpla con las tareas, sea transparente y asegúrese de que todos aprendan de la experiencia.
Vea también una de las respuestas a continuación. "Bueno, ¡el postor más bajo lo demuestra!" no me parece un buen enfoque. Además, esto vinculará automáticamente una historia de usuario a un determinado miembro del equipo, a quien se podría culpar al final ("¡Te lo dijimos!").
Te dijimos que eso es algo bueno cuando es verdad, y el ambiente de trabajo es bueno. Te lo dijimos así enseña.

Respuestas (4)

TL;DR

Gran parte del valor de Scrum para una organización está en la creación de transparencia. El 100% de acuerdo no es el objetivo real de planificar el póquer; el objetivo es en realidad reducir el cono de incertidumbre en torno a las estimaciones de características tanto como sea posible, y hacer que el nivel de esfuerzo y los riesgos potenciales del proyecto de cada historia sean visibles para las partes interesadas a través de su representante elegido, el propietario del producto.

El póquer de planificación puede tener varias rondas

Como se explica en planningpoker.com :

Es muy probable en este punto que las estimaciones difieran significativamente... Si las estimaciones difieren, los estimadores altos y bajos explican sus estimaciones... El grupo puede discutir la historia y sus estimaciones durante unos minutos más... Después de la discusión, cada estimador vuelve a estimar seleccionando una tarjeta.

El punto es que puede seguir reestimando mientras las opiniones converjan. La clave, por supuesto, es que las personas deben hablar sobre por qué sus estimaciones son atípicas, para que el equipo pueda considerar esta información al volver a estimar cada ronda. Si todavía tiene valores atípicos después de que se haya agotado la discusión o cuando el período de tiempo haya expirado, entonces debe usar el proceso definido por su equipo para encontrar un compromiso razonable.

Opciones de compromiso dentro del equipo

Puede hacer lo que parezca razonable en tales casos. Generalmente, los equipos acuerdan de antemano un proceso de compromiso, pero está bien cambiarlo sobre la marcha para que el resultado final siempre sea algo razonable.

Algunas opciones de compromiso incluyen:

  1. Deseche los valores atípicos y luego calcule la media. Este suele ser mi método preferido cuando una historia se ha descompuesto correctamente.
  2. Calcule el promedio, incluidos los valores atípicos.
  3. Divida las tareas polémicas en historias separadas pero dependientes que se puedan estimar por separado.
  4. Recordando que las estimaciones son conjeturas educadas, no promesas escritas en piedra.

La conclusión es que el equipo puede (y debe) hacer su mejor suposición y seguir adelante. Si el equipo no puede llegar a un consenso, o al menos estar de acuerdo en no estar de acuerdo, es posible que tenga un problema subyacente con la calidad de la historia que se está discutiendo.

Opciones de compromiso con el propietario del producto

A veces el problema es la historia que se estima. Un punto clave aquí es que todas las historias se deben estimar para ver si encajan dentro del sprint actual, pero las historias que se estiman no tienen que ser copias literales de los elementos actuales de la cartera de productos.

Recuerde, la primera mitad de la planificación de Sprint implica la participación del propietario del producto, por lo que una estimación de la historia polémica es una oportunidad perfecta para trabajar mano a mano con el PO para volver a definir o refactorizar las historias que tienen problemas potenciales. El PO puede trabajar con el equipo para dividir o reescribir historias, o volver a priorizar el Product Backlog sobre la marcha para cambiar una historia diferente que encaje mejor dentro del sprint actual.

Esta es una buena respuesta, sin embargo, me gustaría agregar otra solución para la incertidumbre: tener un pico o alguna investigación para responder la pregunta específica que causa la incertidumbre. Esto podría significar que una hora puede influir en el equipo para ponerse de acuerdo sobre el '2' o el '20'.

digamos que surgen dos opiniones. Algunos ven esto como una historia bastante fácil (por ejemplo, 2 puntos) y otros prevén complicaciones técnicas y juzgan que la historia debería ser de 20 puntos.

El propietario del producto debe pedirles a aquellos que ven esta historia como un indicador de 20 puntos que la dividan en 3-5 piezas de puntos; esto ayudará a identificar el punto problemático y (si es necesario) agregar uno o más picos de investigación para aclarar la situación.

Gran respuesta, aunque es de esperar que cualquier miembro del equipo pueda hacer esto también, no solo el propietario del producto.

¡Es una brecha muy grande entre 2 y 20 puntos! El OP no dijo si la historia tenía criterios de aceptación comprobables en la lista. En mi experiencia, eso elimina gran parte de los malentendidos sobre el alcance del trabajo.

El OP afirma que el alcance se entiende comúnmente dentro del equipo. Entonces, una posibilidad es, como señaló Dangda, que algunos miembros del equipo conozcan el código base mejor que los demás.

En cualquier caso, el enfoque prudente sería programar primero una historia de investigación de un punto para construir una prueba de concepto. Según el resultado, todo el equipo puede aprender algo y avanzar con más confianza y cohesión.

La solución parece sencilla. Otorgue 2 puntos a la historia y asigne la historia a uno de los desarrolladores que esté de acuerdo en que es una historia de 2 puntos.

Generalmente, cuando tenemos desacuerdos, son puntajes de 2v3 o 3v5. Nunca he visto uno 2v10 o 2v20. Si está cerca, generalmente obtendremos la puntuación solicitada por el desarrollador que trabajará en la historia.

¿Cómo ayudaría la asignación de una historia potencialmente mal estimada a un individuo específico con el principio básico de Scrum de "tener éxito o fracasar como equipo"? Esto parece un olor a proyecto; es solo un representante para responsabilizar a las personas por un proceso de equipo.
@Gnome: No. O el estimador fue correcto, en cuyo caso puede explicar por qué estuvo en lo correcto en la retrospectiva y aumentar el conocimiento del equipo, o estaban equivocados y aprenderán por qué y serán mejores la próxima vez. Mejorar a las personas es una gran parte de mejorar a un equipo.
@CodeGnome: porque un desarrollador puede saber dónde está un código que puede aprovechar para tomarse un tiempo importante del proyecto. Pero a menos que ya entiendas ese código, habrá que pasar un tiempo aprendiendo para que puedan hacer los cambios. Es posible que alguien que ya conoce ese código base pueda hacer algo en 2 días que tomaría de 3 a 4 semanas para alguien que no lo sabe.
Durante la Estimación, el equipo debe estimar la funcionalidad, no el esfuerzo de implementación. Entonces, los 2 puntos son dos puntos de características, no 2 puntos de carga de trabajo. Esto, más el hecho de que el SM no asigna tareas, no hace que esta dirección me parezca correcta.
@TeXter - Entonces, ¿está diciendo que el equipo está debatiendo qué tan importante es la función y no cuánto esfuerzo llevará desarrollarla?
@Chad: Los diferentes equipos estiman de manera diferente y, por lo tanto, un punto difiere. Hay un par de artículos aquí, por ejemplo, pm.stackexchange.com/questions/2765/… . En este caso/equipo en particular, una parte del equipo dice: esto es algo que solíamos hacer por 2 puntos en el pasado, mientras que la otra parte dice: no, esto es diferente y nuevo, nos costará "investigación" durante el desarrollo y tiene incertidumbre, por lo tanto tiene más puntos.
@TeXter - Entonces, si el equipo de una parte dice que lo hizo antes, déles la tarea por 2 puntos, no veo el problema
"Porque un desarrollador puede saber dónde está un código que puede aprovechar para tomarse un tiempo libre significativo del proyecto": este podría ser un buen olor de proyecto que indica una gran falta de intercambio de conocimientos. Esto también podría indicar demasiada selección selectiva de tareas/historias de usuarios por parte de los desarrolladores, lo que resulta en una concentración del conocimiento en la base del código. Esto debe evitarse tanto como sea posible.
@IanS. Sospecho que es más probable que el tipo de los 10 puntos esté tratando de mejorar su puntaje... Pero estaba tratando de darle un buen giro a esto.
¿Cómo debe manejar un equipo los desacuerdos sobre las estimaciones de puntos de historia en Scrum?
RespuestasAquíPolítica de privacidad1y, 1v