La carta ? no es abstención: úsala como una decisión de refinamiento
En planning poker, la carta ? suele aparecer en un momento incómodo: alguien no puede estimar, el resto espera y la conversación corre el riesgo de desviarse.
Publicado el
En planning poker, la carta ? suele aparecer en un momento incómodo: alguien no puede estimar, el resto espera y la conversación corre el riesgo de desviarse. La reacción habitual es pedir una explicación rápida y votar otra vez. A veces funciona. Otras veces solo convierte una historia confusa en un número aparentemente preciso.
La utilidad de ? está precisamente en no tratarla como un voto débil. Es una señal de proceso: antes de estimar, el equipo necesita decidir si falta una aclaración pequeña, una división de alcance, una dependencia externa o una conversación de producto. La guía de ayuda de Stimo lo resume de forma práctica: ? indica falta de información para estimar y, si aparecen muchos ?, conviene aplazar la estimación o dividir la historia. La FAQ añade un matiz importante: otra ronda tiene sentido cuando cambia el entendimiento o cuando hay mucha dispersión, no como reflejo automático.
Este artículo propone un protocolo reutilizable para Scrum Masters, Product Owners y equipos ágiles: leer la carta ? como una decisión pendiente, no como una molestia que hay que despejar cuanto antes.
Qué significa realmente votar ?
Votar ? no significa necesariamente que una persona no haya prestado atención, ni que la historia sea mala, ni que el equipo esté bloqueado. Significa algo más concreto: con la información disponible, esa persona no puede convertir la historia en una estimación responsable.
La diferencia importa. Si interpretamos ? como falta de compromiso, presionamos para que la persona elija un número. Si lo interpretamos como falta de información, abrimos una conversación útil.
Una buena pregunta de facilitación no es: ¿qué número pondrías si tuvieras que poner uno? La pregunta correcta es: ¿qué información te falta para poder estimar?
A partir de ahí, la carta ? puede apuntar a cuatro causas frecuentes:
- Falta de objetivo: no está claro qué problema resuelve la historia.
- Falta de criterio de aceptación: no se sabe cuándo estaría terminada.
- Falta de alcance: hay varias interpretaciones posibles del trabajo.
- Falta de contexto técnico, de UX, QA, datos, seguridad o dependencias.
La estimación relativa puede ayudar a comparar esfuerzo, complejidad e incertidumbre, como explican guías de estimación ágil como la de Atlassian sobre story points. Pero para comparar hace falta una unidad de conversación mínima: todos deben estar hablando de la misma historia.
Protocolo DCA: duda, causa y acción
Para evitar debates circulares, usa la carta ? con un protocolo de tres pasos: DCA.
1. Duda: convertir el ? en una frase concreta
Cada persona que votó ? completa esta frase:
- No puedo estimar porque no sé si...
- No puedo estimar hasta confirmar...
- No puedo estimar sin decidir...
La regla es que la duda debe ser accionable. No sirve decir: la historia está verde. Sí sirve decir: no sé si la exportación incluye filtros guardados o solo el estado actual de la pantalla.
2. Causa: clasificar qué tipo de falta de información hay
Usa esta matriz rápida:
| Causa del ? | Señal típica | Acción recomendada |
|---|---|---|
| Aclaración pequeña | Una duda concreta que el PO puede responder en la sala | Aclarar, actualizar la historia y votar otra vez si cambió el entendimiento |
| Criterios incompletos | El equipo no sabe cómo validar el resultado | Añadir criterios de aceptación antes de estimar |
| Alcance ambiguo | Dos personas imaginan soluciones distintas | Dividir o acotar explícitamente |
| Dependencia externa | Falta una decisión, dato o equipo externo | Registrar responsable y aplazar si bloquea la estimación |
| Riesgo técnico desconocido | No se sabe si la solución es viable | Crear spike o tarea de investigación, no forzar puntos |
3. Acción: cerrar una decisión, no una discusión
Después de clasificar, el facilitador debe cerrar con una de estas cuatro salidas:
- Estimar ahora: la duda se resolvió y el entendimiento cambió.
- Reescribir antes de votar: falta un criterio o una definición breve.
- Dividir: el equipo detectó más de una pieza estimable.
- Aplazar: falta información externa o investigación.
La decisión debe quedar explícita. Si no, la misma historia volverá al siguiente refinamiento con el mismo ? y una conversación parecida.
Checklist para decidir en dos minutos
Cuando aparezca ?, no abras una conversación ilimitada. Prueba esta secuencia de facilitación:
- Cuenta los ? sin revelar nombres como argumento. La cantidad orienta, pero no decide por sí sola.
- Pide una frase de duda por persona. Máximo 20 segundos cada una.
- Agrupa las dudas. ¿Son la misma duda, dudas diferentes o señales de alcance amplio?
- Pregunta si alguien puede resolverlas ahora. Si la respuesta está en la sala, se aclara.
- Decide la acción: estimar, reescribir, dividir o aplazar.
- Solo haz otra ronda si cambió algo relevante. Una segunda votación sin nueva información suele producir números más cómodos, no mejores decisiones.
Esta última regla es clave. La FAQ de Stimo recomienda abrir otra ronda cuando cambia el entendimiento o hay dispersión. Aplicado a la carta ?, eso evita repetir votos por inercia.
Si usas una herramienta de planning poker online, las capacidades deben apoyar esta conversación, no reemplazarla. En Stimo, por ejemplo, los perfiles votantes estiman en privado y el organizador revela resultados y puede abrir una nueva ronda. Esa dinámica ayuda a evitar anclajes prematuros, pero la calidad de la decisión sigue dependiendo de cómo el equipo formule y cierre las dudas.
Ejemplo aplicado: exportación de informes
Ejemplo hipotético. Un equipo está refinando esta historia:
Como responsable financiero, quiero exportar un informe mensual en CSV para analizarlo en una hoja de cálculo.
Primera ronda de planning poker: dos personas votan 3, una vota 5, dos votan ?.
El facilitador no pide un número alternativo. Aplica DCA.
Duda 1: No puedo estimar porque no sé si el CSV debe respetar los filtros aplicados en pantalla o exportar todo el mes.
Duda 2: No puedo estimar sin saber si hay que incluir importes con impuestos desglosados.
La causa no parece técnica todavía. Es alcance y criterio de aceptación. El Product Owner aclara que el primer incremento debe exportar solo el estado actual de la pantalla y que el desglose de impuestos no entra en esta historia.
Opciones del equipo:
- Votar otra vez directamente.
- Dividir en dos historias: exportación básica y desglose fiscal.
- Aplazar hasta hablar con finanzas.
La decisión razonable: actualizar la historia con dos criterios de aceptación y votar de nuevo.
Criterios añadidos:
- La exportación respeta los filtros aplicados en pantalla.
- El CSV incluye total de importe, pero no desglose fiscal por impuesto.
Segunda ronda: 3, 3, 3, 5, 3. Ahora la conversación sobre el 5 puede centrarse en complejidad real, no en ambigüedad de alcance. Si la persona que votó 5 ve un riesgo en permisos, formatos o volumen de datos, se conversa. Si no cambia la comprensión, el equipo puede cerrar con criterio.
Lo importante no es que la estimación baje o suba. Lo importante es que ? convirtió una ambigüedad en una decisión de producto.
Errores comunes al interpretar la carta ?
Forzar un número para mantener el ritmo. Un refinamiento rápido que deja dudas importantes solo traslada el coste al Sprint.
Convertir cada ? en una investigación larga. No todas las dudas requieren aplazar. Algunas se resuelven con una frase de criterio de aceptación.
Permitir dudas abstractas. Si alguien dice no lo veo claro, el siguiente paso es pedir una frase verificable: qué no está claro, qué opción cambia la estimación y quién puede decidirlo.
Hacer otra ronda sin cambiar nada. La segunda ronda es útil cuando hay nuevo entendimiento. Si nadie aprendió nada entre rondas, el resultado puede ser consenso superficial.
Confundir falta de información con desacuerdo técnico. Una persona puede votar ? porque no entiende el alcance; otra puede votar 13 porque entiende el alcance y ve riesgo. Son conversaciones distintas.
Este enfoque conecta con un principio ágil básico: valorar individuos e interacciones por encima de procesos y herramientas, como recuerda el Agile Manifesto. La carta ? no es el proceso decidiendo por el equipo; es una invitación a conversar mejor.
Conclusión práctica
La próxima vez que aparezca ?, no lo trates como un voto incompleto. Trátalo como una decisión de refinamiento pendiente.
Usa esta frase para cerrar cada caso:
La historia no se estima todavía porque falta ___; la acción acordada es ___; la persona responsable es ___; volveremos a estimar cuando ___.
Si el hueco se puede completar en la sala, completa y vuelve a votar. Si revela una historia demasiado grande, divide. Si depende de información externa, aplaza con responsable. Esa disciplina evita estimaciones decorativas y convierte el planning poker en una conversación más clara sobre producto, riesgo y alcance.
Fuentes consultadas
- Stimo · Guía de ayuda: uso de salas, votación privada, papel del organizador y recomendación de llegar con historias pequeñas, criterios visibles y dudas concretas.
- Stimo · Preguntas frecuentes: interpretación de la carta ?, uso de nuevas rondas y roles observadores en la sesión.
- Atlassian · Story points y estimación ágil: contexto general sobre estimación relativa y planning poker.
- Agile Manifesto: valores ágiles sobre colaboración, interacción y adaptación.
¿Listo para ponerlo en práctica?
Crear una sala en Stimo