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

Con tanta variación en la estimación, parece que el trabajo, tal como está definido actualmente, aún no está listo para la estimación. Basado en esa amplia dispersión en las estimaciones, diría que el equipo no tiene una comprensión clara de lo que se requiere para completar el trabajo. A menos que el trabajo sea crítico y deba iniciarse y terminarse lo más rápido posible, recomendaría dedicar más tiempo a refinar el trabajo, ya sea en la parte de la capacidad del equipo asignada al refinamiento del trabajo pendiente o planificada y programada en forma de un Espiga.

Esperaría que saliera bastante de este refinamiento adicional. Buscaría puede incluir una breve lista de las tareas o los pasos necesarios para realizar el trabajo y una cuantificación de los riesgos (incluida la deuda técnica). Una vez hecho esto, devolvería el trabajo al equipo para una mayor discusión y ver si comienzan a converger.

Lo primero que debes hacer es animar al equipo a aportar argumentos concretos.

"Las cosas son más complicadas de lo que parecen" o "No creo que esas complicaciones sean válidas" son argumentos muy vagos.

"No estoy de acuerdo, porque el adaptador de base de datos tiene 3.000 líneas de código, por lo que los cambios en esta clase son muy difíciles" o "Encontrar todos los métodos que hacen X lleva mucho tiempo, no debemos subestimar esto" son argumentos mucho mejores, ya que puedes discuta los detalles -> "Encontrar todos los métodos para hacer X es fácil, ¡conozco una expresión regular solo para eso!".

¡También aclare que los puntos no son el centro de la estimación, sino la discusión que lleva al valor de los puntos! Aquí el conocimiento se transfiere de quizás un experto a todo el equipo. Esto muestra obstáculos en los que nadie ha pensado antes, o puede ofrecer atajos que hacen que una tarea aparentemente compleja sea muy fácil.

El Scrum Master puede hacer varios intentos para obtener un consenso sobre los puntos de la historia repitiendo la votación y, por lo general, esto funciona después de 2 o 3 intentos.

Si después de esos intentos sigue sin funcionar, toma la mitad de la mayoría de los votos y toma nota. Una vez completada la tarea, puede verificar qué tan bueno fue el voto y hablar con el equipo al respecto para aprender para estimaciones futuras.

Algunas sugerencias que podrían ayudar, dependiendo de la naturaleza y el tamaño de la historia.

• Organice un tutorial de código para que los miembros del equipo puedan ver los problemas por sí mismos.
• Si la historia es lo suficientemente pequeña como para que algún subconjunto del equipo pueda captarla, entonces tal vez el equipo pueda llegar a un entendimiento de que esas personas trabajarán solas en esta historia en particular y que se debe usar su estimación. Las personas que hacen el trabajo pueden luego informar sobre cómo les fue.
• Si la historia es lo suficientemente grande como para que un consenso sea importante pero no se puede encontrar un consenso, entonces divídala en elementos más pequeños.
• No lo estimes hasta que esté hecho.
• Vaya con la estimación más alta y planifique la capacidad de sprint en consecuencia. El equipo siempre puede incorporar trabajo adicional al sprint si descubre que tiene el ancho de banda.

En Sprint Planning, el rol del Scrum Master no debería ser decirle al equipo cómo lograr el objetivo del sprint, pero sería para alentarlos a aceptar cierta ambigüedad e inspeccionar y adaptarse a medida que avanzan.

Introducción

El objetivo de Planning Poker es ayudar al equipo a dimensionar correctamente la cantidad de trabajo que se incluye en la iteración. Esto evita comprometer en exceso al equipo y garantiza suficiente holgura dentro de un proceso iterativo. No tiene la intención de entregar estimaciones de alta precisión, ofrecer una garantía de devolución de dinero revestida de hierro, o apuntar a niveles más altos de utilización individual y de equipo dentro de un Sprint.

Planning Poker (y Sprint Planning en general) está destinado a proporcionar una estimación "suficientemente buena" basada en el tamaño relativo, el análisis sin anclaje y la alineación impulsada por el consenso. Es simplemente una herramienta en el arsenal del Scrum Master y no es requerida por el marco. Existen otras técnicas de estimación que se pueden utilizar. Incluso cuando se usa correctamente, aún puede ser beneficioso complementar Planning Poker con otras técnicas de planificación y estimación, como la votación de confianza de todo el Sprint (por ejemplo, de puño a cinco), la acumulación de TFB/NFC/1 o los picos de historias.

Diferentes puntos de vista agregan valor

Un elemento de diseño clave de la planificación del póquer es evitar el anclaje . Como resultado, las estimaciones iniciales pueden variar tanto como las perspectivas y suposiciones presentes dentro de su equipo. Especialmente en equipos multifuncionales con personas en forma de I, a menudo encontrará que las estimaciones iniciales varían bastante, aunque también pueden variar con personas en forma de T.

El objetivo de planificar el póquer no es solo llegar a un puntaje único. El objetivo real es alentar a todo el equipo a aprovechar sus diferentes experiencias, perspectivas y suposiciones para llegar a una estimación con la que todo el equipo pueda alinearse, sin permitir que el anclaje deje de lado las discusiones importantes sobre el alcance, la complejidad o la incertidumbre que a menudo conducen a demasiado. estimaciones optimistas o pesimistas.

Asignación de una estimación "suficientemente buena"

Hay muchas formas de abordar las puntuaciones muy divergentes, cada una con ventajas y desventajas. Una lista no exhaustiva incluye:

• Discuta las razones de los deltas y luego vuelva a votar.
• Promedie los votos para crear una puntuación compuesta.
• Elija la puntuación más alta (por ejemplo, errar por el lado de la precaución).
• Descomponga el elemento de trabajo (si se puede dividir o refactorizar) y luego vote por los elementos descompuestos.

Sin embargo, el enfoque más ampliamente aceptado es probablemente el definido por Mike Cohn :

Si todos los estimadores seleccionaron el mismo valor, ese se convierte en el estimado. Si no, los estimadores discuten sus estimaciones. Los estimadores altos y bajos deben compartir especialmente sus razones. Después de una discusión adicional, cada estimador vuelve a seleccionar una carta de estimación y todas las cartas se revelan nuevamente al mismo tiempo.

El proceso de planificación del póquer se repite hasta que se logra el consenso o hasta que los estimadores deciden que la estimación y la planificación ágiles de un artículo en particular deben posponerse hasta que se pueda adquirir información adicional.

Dentro de un contexto de Scrum (y como una buena regla general), la mayoría de los equipos suelen cronometrar el proceso de discusión y votación para evitar que las historias de usuarios problemáticas se conviertan en un sumidero de tiempo. Un temporizador de huevo de 3 o 5 minutos a menudo funciona bien para evitar que las discusiones se prolonguen indefinidamente, y un equipo que no puede llegar a un consenso después de dos o tres rondas de votación sobre un tema puede dejar la historia a un lado (si no es esencial al Sprint Goal), o acuerde una mejor suposición que probablemente sea incorrecta, pero que a menudo es "suficientemente buena" cuando la variación está dentro de un orden de magnitud modesto.

Cuando el equipo no puede alinearse

En algunos casos, puede ser necesario reemplazar la historia con un pico de historia para reducir el cono de incertidumbre. Esta técnica se aplica mejor a las historias que se pueden aplazar, de modo que los resultados del pico se puedan retroalimentar en el Refinamiento del Backlog o en una futura sesión de Planificación de Sprint.

En el raro caso de que un Elemento de la Lista de Producto no se pueda apartar, descomponer o incluso "estimar", el equipo puede trabajar con el Propietario del Producto para ajustar la Lista de Producto, el Sprint Goal o la característica para que sea más estimable. Recuerde que un aspecto clave de la estimación es brindar confianza de que el trabajo incluido en el Sprint se puede completar en un solo cuadro de tiempo, y un Sprint Backlog que no obtiene suficiente confianza del equipo de que cumplirá el Sprint Goal o encajará dentro un solo Sprint debe volver a trabajarse o aceptarse como un riesgo del proyecto.

Las estimaciones de la historia importan menos que la confianza en los objetivos del Sprint

La estimación real de cualquier elemento de la lista de pedidos del Sprint/producto dado suele ser menos importante que la confianza general del equipo en que se puede alcanzar el objetivo del Sprint y que la lista de pedidos del Sprint dará como resultado un incremento potencialmente liberable. Por lo tanto, no se obsesione demasiado con las estimaciones individuales. Lo que realmente importa es la confianza general en el Sprint Backlog que resulta de Sprint Planning.

Como ejemplo de cómo generar un nivel de confianza para un Sprint Backlog determinado, puede considerar la técnica de puño a cinco. Como se describe en SAFe PI Planning , el equipo básicamente crea un puntaje de confianza promedio al votar 0-5 sobre su confianza en que el incremento de trabajo se puede entregar en una sola iteración. La documentación describe esta actividad clave de la siguiente manera:

[L]os equipos votan sobre su confianza en el cumplimiento de los objetivos de IP de su equipo. Cada equipo lleva a cabo una votación de 'puño de cinco'. Si el promedio es de tres dedos o más, la gerencia debe aceptar el compromiso. Si son menos de tres, el equipo reelabora el plan. Cualquier persona que vote con dos dedos o menos debe tener la oportunidad de expresar sus preocupaciones. Esto podría agregarse a la lista de riesgos, requerir una nueva planificación o simplemente ser informativo.

Incluso si cada historia de usuario o elemento del backlog es 100 % preciso (lo que casi nunca sucede en el mundo real), a menudo es posible terminar con un backlog sobrecomprometido. Definir un nivel de confianza para el Sprint Backlog en su conjunto actúa como una función de suavizado para equilibrar las variaciones modestas en las estimaciones por historia. Algunas historias pueden estar sobreestimadas, mientras que otras están subestimadas. Siempre que el equipo tenga confianza en que se puede alcanzar el Sprint Goal y que el Sprint Backlog no desbordará el cuadro de tiempo de un solo Sprint, la imprecisión esperada de Planning Poker (o cualquier otra técnica de estimación de la historia) generalmente se promediará. .

Me gusta usar la secuencia 1,2,3,5,7,10,20,30,50,70,100 para los puntos de la historia. Si los miembros del equipo eligen vecinos, es decir, 20 y 30, simplemente tome un promedio de 25 y siga adelante.

Si el diferencial es más alto, como 7-20, generalmente significa que el alcance de lo que se pide no está claro y los miembros del equipo están pujando por un alcance diferente, o algunos ven dificultades que otros no (cualquiera de las partes puede tener razón al respecto). En realidad, esto es algo valioso para captar y para que el equipo lo discuta.

Por lo general, una discusión alinea a los miembros del equipo en la estimación de puntos de la historia, a menudo el valor más alto, ya que las complicaciones omitidas son más comunes que la "solución milagrosa" desconocida. El punto es que, por lo general, si se estima el mismo resultado y se consideran los mismos desafíos, las personas razonables suelen tener estimaciones similares.

Entonces, en su caso, donde una discusión no conduce a estimaciones similares en las que el equipo puede estar de acuerdo, diría que tiene una bandera roja sobre la interacción y / o habilidad del equipo. Esta debería ser su preocupación en lugar de cómo dimensionar una historia.

Sin embargo, si el equipo no puede encontrar una solución que sea aceptable para todos, una de estas sugerencias puede resolver el problema de manera agradable para el equipo:

• Basado en una breve presentación de las partes en desacuerdo al equipo, deje que el resto del equipo vote en secreto y use el promedio, pero evite que el "mejor postor" sea responsable de cumplir con esto.
• Pregúntele al "postor bajo" cuánto tiempo debe hacer una prueba de concepto y vuelva a revisar la estimación después. Eso debería dar información para que el equipo haga una estimación.

La clave es evitar que el desacuerdo sea conflictivo y crear un "ganador y un perdedor" (en la medida de lo posible).

En mi formación como maestro de scrum, nos enseñaron que el equipo tenía que llegar a un consenso sobre los valores de los puntos.

Si el punto de consternación fue "Si lo hiciera serían 2" y otra persona dice "si lo hiciera serían 20" y todos están de acuerdo en ese punto, entonces la historia obtiene 20 puntos.

Otro asunto confuso es el total de puntos por encima de 13, ¿no sería bueno dividirlos en historias más pequeñas? Entonces, como maestro de scrum, puede entrenar al equipo para que vea dónde están hablando entre sí. Lo más probable es que la persona que piensa que son 20 puntos vea una historia adicional o dos entre las frases "como" y "para que pueda".

Sin embargo, si la persona que piensa que son 20 puntos lo hace porque sabe que tendrá que pasar dos días refactorizando las pruebas de integración, entonces probablemente tenga razón y la persona inconformista, "lo haré en 2" debería realmente simplemente ignorarse a favor de un enfoque más riguroso; allí, creo que depende del propietario del producto asegurarse de que los criterios de aceptación coincidan con las percepciones de cualquiera de los dos miembros del equipo.

En pocas palabras: cavar hasta encontrar la desviación.

Divida la tarea en subtareas para encontrar dónde está la discrepancia; p.ej:

• Diferente comprensión del alcance de la tarea.
• Diferentes estimaciones para las mismas subtareas

Generalmente:

• Puntos de estimación de clúster, por ejemplo 5-10-25-50-100-200-..., para evitar discusiones de un solo dígito.

No recomendaría el enfoque de arriba hacia abajo para tomar la media de las estimaciones, porque :

• Es simplemente resolver una abstracción del problema (cómo satisfacer diferentes opiniones) en lugar de resolver la discrepancia subyacente.
• Todos se sentirán superados.
• La discrepancia puede ser una indicación de otros problemas; véase más arriba.

En el pasado, acepté el 2 y asigné la tarjeta a la persona que dijo que era un 2.

Por lo general, funciona bien y, sinceramente, no te preocupes por las cosas pequeñas aquí.

Solo asegúrese de que la persona que piensa que es un 2 le diga si va a explotar, y si lo hace, pídale que elija otra tarjeta, la acumule y vuelva a estimar la tarjeta en el próximo sprint.

Es solo un 2, no es gran cosa de una forma u otra, tu trabajo es hacer que el equipo funcione, y cualquier resultado será interesante en el retro al final del sprint.

No tiene que ser perfecto, PODRÍA ser que la persona que lo está estimando sepa algo que los demás no saben, déjalos brillar.

Si no lo hacen, habrán aprendido algo útil.

Este es uno de los principales defectos de Agile: las estimaciones se convierten en plazos. El scrum master no técnico opta por las estimaciones más bajas y, de repente, el sprint se estropea. Alternativamente, a las personas que dan las estimaciones más bajas se les dice algo como "Si crees que es tan fácil, entonces codifica". Para salvar las apariencias, pusieron un montón de trabajo extra para entregar una estimación que no quieren admitir que estaba equivocada. Cuando esto comienza a suceder en cada sprint, las personas pierden la esperanza, renuncian y buscan un trabajo en el que no usen Agile. Mi consejo es ir con las estimaciones más largas. Puede agregar más trabajo al sprint más tarde si los elementos terminan antes. Las estimaciones de su personal que previamente han proporcionado estimaciones precisas deberían tener más peso. Si una tarea al principio del sprint tiene una estimación demasiado corta, entonces el tema de cada reunión será "