Publicaciones

Cómo manejar desacuerdos durante Planning Poker

Un equipo ágil diverso sentado alrededor de una mesa durante una sesión de Planning Poker, mostrando tarjetas con diferentes estimaciones mostrando desacuerdo, con un scrum master facilitando la discusión Revelas las tarjetas. Un desarrollador jugó un 3. Otro jugó un 13. La sala se queda en silencio por un segundo, luego todos empiezan a hablar al mismo tiempo. Si ha estado facilitando Planning Poker durante algún tiempo, conoce bien este momento. La mayoría de los scrum masters lo tratan como un problema que hay que resolver rápidamente. Llegar a un consenso, pasar a la siguiente historia. Pero el desacuerdo en sí es la parte más valiosa de toda la sesión. La brecha entre un 3 y un 13 significa que su equipo tiene suposiciones fundamentalmente diferentes sobre el trabajo, y revelar esas suposiciones antes de que comience el sprint es exactamente para lo que sirve la estimación. Así es cómo convertir esos desacuerdos en mejores resultados de sprint en lugar de tiempo perdido.

Por qué los desacuerdos en estimaciones son valiosos

Si su equipo estuviera de acuerdo en todas las estimaciones inmediatamente, no necesitaría Planning Poker en absoluto. Podría simplemente tener una persona que asigne números. La razón por la que existe la revelación simultánea es específicamente para revelar desacuerdos. Cuando las estimaciones divergen, generalmente significa una de tres cosas: Complejidad oculta. Un desarrollador ve una operación CRUD directa. Otro ve un caso límite que implica concurrencia o una integración frágil que necesitará un manejo cuidadoso. Sin el desacuerdo, el equipo se comprometería con la estimación más baja y descubriría la complejidad a mitad de sprint. Diferentes suposiciones sobre el alcance. "Construir la función de búsqueda" significa búsqueda de texto completo con filtros y paginación para un desarrollador y un simple dropdown de coincidencia de cadenas para otro. La brecha en las estimaciones revela que los criterios de aceptación necesitan aclaración antes de que el equipo comience a construir. Requisitos faltantes. Un rango grande a menudo señala que la historia misma está incompleta. Cuando alguien estima alto porque está considerando lo desconocido que otros no han considerado, lo desconocido necesita ser nombrado y resuelto.

La técnica de discusión de valores atípicos

El movimiento de facilitación más efectivo durante planning poker es pedir que hablen primero los valores atípicos. Después de revelar las tarjetas, siempre comience con la persona que estimó más alto y la persona que estimó más bajo. Esto funciona por tres razones:

1. Da la palabra a los valores atípicos. En muchos equipos, la persona que jugó un 2 cuando todos los demás jugaron un 8 permanecerá en silencio a menos que sea específicamente invitada a explicar. Podrían saber algo que nadie más consideró, o podrían malinterpretar la historia. De cualquier manera, necesita escucharlos.
2. Impide que la mayoría aplaste a los valores atípicos. Si cinco personas jugaron un 8 y uno jugó un 2, el instinto natural es presionar al atípico para que se conforme. Comenzar con el atípico señala que su perspectiva importa independientemente de los números.
3. Enfoca la discusión. En lugar de una discusión libre donde todos reafirman su razonamiento, obtiene un debate estructurado entre los dos extremos del espectro. El resto del equipo escucha y ajusta su modelo mental.

Dos desarrolladores de software teniendo una discusión respetuosa y comprometida sobre una pantalla de computadora portátil, uno señalando la pantalla explicando su enfoque técnico mientras el otro escucha atentamente, con tarjetas de estimación visibles en una pizarra

Cómo facilitar la discusión de valores atípicos

Use estos puntos específicos para guiar conversaciones productivas de valores atípicos:

• Al estimador más bajo: "Camínenos a través de su enfoque. ¿Cómo se ve esta historia en su cabeza?"
• Al estimador más alto: "¿Qué riesgos o complejidad ve que podrían no ser obvios?"
• A ambos: "¿Qué suposiciones está haciendo sobre el alcance?"
• Después de que hablen ambos: "¿Alguien quiere cambiar su estimación basándose en lo que acaba de escuchar?"

Luego vuelva a votar. La mayoría de las veces, el equipo converge después de una ronda de discusión de valores atípicos porque la conversación reveló un malentendido de alcance o un riesgo técnico que cambia el modelo mental de todos.

Causas comunes de desacuerdo

Entender por qué las estimaciones divergen lo ayuda a resolver desacuerdos más rápido. Aquí están los patrones que verá con más frecuencia:

Comprensión diferente del alcance

Esta es la causa más común. Dos desarrolladores leen la misma historia de usuario e imaginan trabajo completamente diferente. Uno interpreta "agregar notificaciones" como un mensaje de notificación en la aplicación. Otro lo interpreta como notificaciones por correo electrónico con plantillas, seguimiento de entrega y manejo de cancelación de suscripción. Cómo resolverlo: Pida al propietario del producto que aclare el alcance en el acto. Si el PO no está en la sala, estacione la historia y llévela a la próxima sesión de refinamiento del backlog.

Diferentes enfoques técnicos

Dos desarrolladores podrían estar de acuerdo en el alcance pero no en cómo construirlo. Uno planea extender un servicio existente. Otro cree que el servicio existente no puede manejar la carga y quiere construir uno nuevo. Cómo resolverlo: Esto no es un problema de estimación; es una decisión de diseño. Que el equipo discuta brevemente los compensaciones y elija un enfoque. Si necesita más investigación, cree un spike y estime la historia en la próxima sesión.

Brechas de experiencia

Un desarrollador sénior que ha construido características similares antes estima un 3. Un desarrollador de nivel medio que nunca ha tocado esa parte de la base de código estima un 8. Ambos son honestos, y ambos tienen razón según su propia experiencia. Cómo resolverlo: Estime para el equipo, no para el individuo. Pregunte: "Si un miembro típico del equipo tomara esto, ¿cuánto esfuerzo es?" Si solo una persona puede hacer el trabajo, ese es un riesgo de compartir conocimiento digno de señalar, pero no debería inflar la estimación. La estimación debería reflejar la complejidad inherente, no quién resulta estar haciendo el trabajo.

Criterios de aceptación poco claros

Cuando las historias son vagas, las estimaciones se convierten en conjeturas. "Mejorar el rendimiento" sin un número objetivo. "Hacer el panel más amigable" sin maquetas. Estas historias no están listas para estimación. Cómo resolverlo: Envíalas de vuelta. Las historias que no se pueden estimar deben volver al refinamiento. Si ve este patrón con frecuencia, el problema podría estar en cómo se escriben las historias de usuario. También puede usar un analizador de complejidad de estimación para marcar historias insuficientemente especificadas antes de que lleguen a la mesa de estimación.

Timeboxee sus discusiones de estimación

Aquí es donde va mal la mayoría de la facilitación. Un desacuerdo sale a la luz, la discusión es productiva durante dos minutos, y luego se convierte en un debate de arquitectura de 15 minutos. El equipo estima cuatro historias en una hora en lugar de doce. Establezca una caja de tiempo dura de cinco minutos por historia. Así es como la hace cumplir: Un disparo cercano desde arriba de una mesa de reunión con tarjetas de planning poker mostrando diferentes estimaciones, un temporizador y notas adhesivas con texto de historia de usuario, transmitiendo debate de estimación estructurado

Por qué nunca debe promediar estimaciones

Cuando un equipo no puede estar de acuerdo, es tentador dividir la diferencia. "Tenemos un 5 y un 13, llamémoslo 8." Eso se siente justo y eficiente. No es ninguno de los dos. El promediado oculta el desacuerdo en lugar de resolverlo. La persona que dijo 13 tiene información sobre riesgos o complejidad que no desaparece porque escribiste 8. Cuando comienza el sprint, esos riesgos siguen ahí, y el equipo se ha comprometido con una estimación que no refleja ninguna perspectiva con precisión. El promediado también derrota el propósito de usar una escala no lineal como Fibonacci. Los saltos entre valores (1, 2, 3, 5, 8, 13, 21) son intencionalmente grandes para forzar a los equipos a hacer distinciones significativas. Un 5 y un 13 no son "lo suficientemente cercanos para encontrarse en el medio." Representan comprensiones fundamentalmente diferentes del trabajo. Para más sobre por qué las escalas de puntos de historia están diseñadas de esta manera, vea nuestro análisis profundo. Qué hacer en lugar de promediar:

• Use la técnica de discusión de valores atípicos para revelar la causa raíz del desacuerdo
• Si debe elegir un número sin consenso, vaya con la estimación más alta. Es más seguro sobrestimar que subestimar
• Si la brecha es extrema (por ejemplo, 2 vs. 21), la historia no está lista. Envíela de vuelta al refinamiento

Use la revelación simultánea para prevenir el sesgo de anclaje

El sesgo de anclaje es la tendencia a confiar mucho en la primera información que escucha. En la estimación, esto significa que el primer número dicho en voz alta se convierte en el ancla para el pensamiento de todos los demás. Si un desarrollador sénior dice "esto se siente como un 3" antes de que las tarjetas se revelen, el resto del equipo inconscientemente se ajusta hacia ese número. Planning poker anónimo resuelve esto asegurando que todas las estimaciones se envíen antes de que cualquiera se revele. Nadie ve el número de nadie más hasta que todos se han comprometido. Esto no es solo un complemento agradable; es una salvaguarda estructural contra uno de los sesgos cognitivos más bien documentados en la toma de decisiones. Herramientas como Kollabe hacen cumplir automáticamente la revelación simultánea. Las tarjetas permanecen ocultas hasta que cada participante ha seleccionado su estimación. Esto es significativamente más confiable que las tarjetas físicas, donde alguien inevitablemente las muestra temprano o las sostiene en un ángulo. Los equipos que carecen de seguridad psicológica se benefician especialmente de la estimación anónima. Cuando los desarrolladores junior sienten que su estimación honesta podría ser juzgada por miembros sénior del equipo, se conforman con lo que los sénior juegan. El anonimato elimina esa dinámica por completo.

Cuándo dejar de discutir y dividir la historia

A veces, un desacuerdo no se trata de malentendido. Ambos lados entienden completamente la historia, pero el trabajo es genuinamente complejo e incierto. Cuando eso sucede, la respuesta no es un debate más largo. La respuesta es dividir la historia. Señales de que una historia necesita dividirse en lugar de más discusión:

• Las estimaciones abarcan más de tres valores de Fibonacci (por ejemplo, 3 a 21)
• La discusión sigue volviendo a "depende de..." múltiples escenarios
• Diferentes partes de la historia podrían entregarse independientemente
• El equipo identifica áreas de riesgo distintas que podrían aislarse

Cómo dividir efectivamente: Divida a lo largo de líneas de valor, no capas técnicas. "Construir la API" y "Construir la UI" no son divisiones buenas porque ninguna entrega valor al usuario sola. En su lugar, divida por escenario de usuario: "Buscar por nombre" y "Buscar con filtros avanzados" entrega algo que un usuario realmente puede usar. Después de dividir, reestime cada pieza. A menudo encontrará que la suma de las partes es mayor que la estimación original, y eso está bien. La estimación original fue incorrecta porque la historia era demasiado grande para estimar con precisión. Las historias más pequeñas son más fáciles de estimar, construir y verificar.

La técnica de votación de confianza

Ha discutido los valores atípicos, ha vuelto a votar y ha llegado a un número que el equipo acepta. Pero la aceptación no es lo mismo que confianza. La votación de confianza "puño de cinco" atrapa la diferencia. Después de llegar a consenso en una estimación, pida a cada miembro del equipo que levante simultáneamente uno a cinco dedos:

Dedos	Significado
5	Completamente confiado, sin preocupaciones
4	Confiado, incertidumbre menor
3	Aceptable, algunas reservas
2	Incómodo, preocupaciones significativas
1	Fuertemente en desacuerdo, no debe comprometerse

Si alguien muestra un 1 o 2, tiene 60 segundos para explicar su preocupación. A menudo revela un riesgo que el equipo debe notar incluso si la estimación no cambia, como una dependencia de otro equipo o una pieza de código heredado que podría resistir cambios. Esto lleva 15 segundos por historia cuando la confianza es alta y solo agrega tiempo cuando hay una preocupación digna de escuchar. Es una red de seguridad de bajo costo contra el desacuerdo silencioso.

Juntándolo todo: una lista de verificación de facilitación

Los desacuerdos durante planning poker no son un signo de disfunción. Son el mecanismo a través del cual su equipo construye una comprensión compartida. El objetivo no es eliminar el desacuerdo. Es tener una forma estructurada de extraer la información que el desacuerdo contiene y convertirla en mejores estimaciones y mejores resultados de sprint. Para una vista más amplia de enfoques de estimación más allá de planning poker, consulte nuestra guía de técnicas de estimación ágil.