Estimación relativa con planning poker para equipos de desarrollo

Domina cómo estimar esfuerzo con estimación relativa y la serie de Fibonacci aplicadas mediante planning poker. Este enfoque compara elementos entre sí, integra complejidad, incertidumbre y tamaño, y ayuda al equipo a llegar a consenso sin caer en horas o días, fomentando una comprensión compartida.

¿Qué es la estimación relativa y por qué usarla?

La estimación relativa asigna un tamaño comparativo a cada elemento de la lista de producto, evitando unidades de tiempo fijas. Se consideran tres variables clave: complejidad, incertidumbre y tamaño. Para estandarizar, se usa la serie de Fibonacci como escala de pesos y se define un pivote que sirve de referencia común.

¿Cómo elegir el pivote con serie Fibonacci?

• Se selecciona un elemento que todos comprenden y ponderan igual: el pivote.
• Ejemplo con animales: zorro = peso 3 como pivote. Gorila, por ser mayor, recibe 8. Elefante, mucho más grande, 20.
• La comparación directa facilita calibrar el esfuerzo relativo del resto.

¿Qué variables considerar: complejidad, incertidumbre y tamaño?

• Complejidad: integración técnica, casos límite, dependencias.
• Incertidumbre: información incompleta, decisiones pendientes.
• Tamaño: alcance funcional, trabajo implicado.

¿Cómo funciona el planning poker paso a paso?

El planning poker es una técnica basada en juego que usa cartas de la serie de Fibonacci para estimar en simultáneo, promover debate y alcanzar acuerdos informados. El proceso se repite hasta lograr un consenso o un rango de estimación aceptable.

¿Qué rol tiene el product owner y el equipo?

• El product owner presenta cada elemento de la lista de producto.
• Las personas desarrolladoras hacen preguntas para aclarar qué se requiere.
• Todos entienden qué se debe construir antes de estimar.

¿Cómo se vota y se llega a consenso?

• Cada desarrollador elige una carta en privado con su estimación.
• Se revelan todas las cartas al mismo tiempo.
• Se discuten diferencias altas o bajas para entender el esfuerzo real.
• Se vuelve a votar hasta converger.

¿Qué aprendimos del ejemplo de la app de idiomas?

Historia de usuario: “Como usuario quiero poder grabar mi pronunciación y compararla con la de un hablante nativo para mejorar mi acento”. Las primeras estimaciones fueron 8, 3 y 13. Surgieron argumentos sobre integración de grabación, comparación de audios, uso de una API existente y permisos de micrófono en múltiples plataformas. Tras discutir, el equipo revotó y convergió hacia 8 o 13, logrando mejor entendimiento compartido.

¿Qué riesgos y dependencias salieron a la luz?

• Permisos de micrófono en múltiples plataformas.
• Integración de audio delicada.
• Dependencia de una API para comparar audios.
• Complejidad de comparar y procesar grabaciones.

¿Por qué el planning poker mejora la comunicación?

• Obliga a explicitar supuestos y riesgos.
• Reduce la incertidumbre mediante debate estructurado.
• Genera conocimiento homogéneo sobre la complejidad.
• Alinea expectativas y acelera el consenso.

¿En qué otras situaciones o contextos aplicarías el planning poker? Comparte tus ideas y experiencias en los comentarios.