Cuando aparece la carta ?: un protocolo para no estimar a ciegas

En una sesión de planning poker hay un momento incómodo: se revelan las cartas, casi todo el mundo espera un número y aparece un ?. A veces una sola persona lo usa. Otras, aparecen varios. La reacción habitual es intentar resolverlo rápido: alguien explica algo, se vota otra vez y se busca cerrar la historia.

El problema no es la carta. El problema es tratarla como ruido.

En planning poker, la estimación solo es útil si el equipo compara esfuerzo con un contexto compartido. Atlassian describe los story points como una estimación relativa: no buscan medir horas exactas, sino comparar complejidad, esfuerzo e incertidumbre frente a referencias conocidas. Si alguien vota ?, está diciendo que no puede hacer esa comparación con responsabilidad.

Leída así, la carta ? no retrasa el refinamiento. Lo protege. Evita convertir una duda real en un número aparentemente consensuado. Y encaja mejor con una agilidad orientada a colaboración y respuesta al cambio, no a cerrar planes por inercia, como recuerda el Agile Manifesto.

Este artículo propone un protocolo sencillo para decidir qué hacer cuando aparece ?: preguntar, dividir o aplazar. No depende de una herramienta concreta, aunque si usas Stimo, su ayuda documenta la carta ? como señal de falta de información y permite abrir nuevas rondas cuando el entendimiento cambia.

Qué está diciendo realmente un ?

Un ? no significa necesariamente que la historia esté mal escrita, que la persona no haya prestado atención o que el equipo esté bloqueando la sesión. Puede significar cuatro cosas distintas:

1. Falta alcance: no está claro qué entra y qué queda fuera.
2. Falta dependencia: hay una integración, permiso, dato o decisión externa que condiciona el trabajo.
3. Falta riesgo: el equipo sospecha una complejidad técnica, de diseño, QA o negocio que no se ha hecho explícita.
4. Falta criterio de aceptación: no se sabe cuándo la historia estará terminada.

La diferencia importa porque no todas las dudas se resuelven igual. Si falta un criterio de aceptación, quizá baste con formularlo. Si falta una dependencia externa, quizá no tenga sentido estimar todavía. Si hay dos riesgos grandes mezclados, quizá la historia deba dividirse.

La recomendación editorial es tratar cada ? como una petición de contexto, no como un voto incompleto. La persona que lo usa no tiene que defender una postura; tiene que convertir su duda en una pregunta observable.

La matriz: preguntar, dividir o aplazar

Antes de votar de nuevo, dedica un minuto a clasificar el ?. Esta matriz ayuda a no caer en discusiones circulares:

Señal observada	Pregunta útil	Decisión probable
Una persona vota ? y el resto converge	¿Qué dato te falta para elegir entre dos tamaños?	Aclarar y hacer otra ronda
Varias personas votan ?	¿Qué parte de la historia no podemos explicar igual?	Reescribir alcance o criterios antes de votar
Hay ? y números muy separados	¿Estamos estimando la misma solución o varias opciones?	Separar alternativas o dividir la historia
El ? depende de un tercero	¿Podemos resolverlo ahora con alguien presente?	Si no, aplazar la estimación
El ? revela trabajo oculto de QA, UX o datos	¿Ese trabajo pertenece a esta historia o a otra?	Dividir o añadir criterio explícito

La FAQ de Stimo recoge una idea útil para equipos que votan online: la carta ? no participa en el cálculo numérico y, si aparecen varias dudas o mucha dispersión, conviene conversar y abrir otra ronda. El punto clave no es la herramienta, sino la disciplina: una nueva ronda solo tiene sentido si el entendimiento cambió.

Protocolo de 90 segundos para usar el ?

Cuando aparezca un ?, prueba esta secuencia. Es breve a propósito: el objetivo no es abrir un debate infinito, sino decidir si el equipo ya puede estimar.

1. Nombrar la señal sin juicio.

La facilitación puede decir: “Tenemos uno o varios ?. Antes de votar otra vez, convirtamos eso en preguntas”. Evita frases como “¿qué no has entendido?”, porque desplazan la responsabilidad a la persona. Mejor: “¿qué información nos falta como equipo?”.

2. Pedir una pregunta concreta por cada ?.

La persona que votó ? formula una duda en una de estas categorías:

• Alcance: ¿incluye también el flujo de cancelación?
• Dependencia: ¿ya existe el endpoint o hay que crearlo?
• Riesgo: ¿sabemos cómo validar los datos históricos?
• Criterio de aceptación: ¿qué comportamiento esperamos si falla el pago?

3. Responder solo lo estimable.

No intentes resolver el diseño completo. Basta con aclarar lo necesario para comparar tamaño. Esto conecta con la estimación relativa: no necesitas una especificación exhaustiva, pero sí un contexto suficiente para calibrar.

4. Elegir una de tres salidas.

• Si la duda se resuelve y la historia mantiene su forma: nueva ronda.
• Si la duda cambia el alcance o mezcla trabajos distintos: dividir.
• Si la duda depende de información que no está disponible: aplazar.

5. Registrar la decisión mínima.

No hace falta una página de documentación. Basta con dejar visible la pregunta respondida, el criterio añadido o el motivo del aplazamiento. DORA insiste en que la mejora de equipos de software es sociotécnica: no basta con mirar métricas o herramientas; hay que mejorar cómo el sistema de trabajo aprende y decide. Un ? bien gestionado es una micropráctica de aprendizaje.

Ejemplo aplicado: una historia aparentemente pequeña

Ejemplo hipotético: un equipo estima esta historia:

“Como cliente, quiero guardar una dirección de envío para reutilizarla en futuras compras”.

Primera ronda:

• Backend: 3
• Frontend: 5
• QA: ?
• UX: ?

La tentación sería preguntar rápido a QA y UX, aclarar algo y volver a votar. Pero el facilitador aplica el protocolo.

QA convierte su ? en una pregunta: “¿Hay que validar direcciones internacionales o solo nacionales?”. UX añade otra: “¿El usuario puede editar la dirección desde checkout o desde su perfil?”.

El Product Owner responde que inicialmente solo se contemplaban direcciones nacionales, pero que la edición desde perfil también sería deseable. El equipo detecta entonces que hay dos decisiones mezcladas:

1. Guardar una dirección nacional durante checkout.
2. Gestionar direcciones guardadas desde el perfil.

Opciones posibles:

• Opción A: votar otra vez la historia completa. Rápida, pero arriesga inflar la estimación y mezclar dos flujos.
• Opción B: dividir en dos historias. Hace visible el alcance y permite priorizar el flujo mínimo.
• Opción C: aplazar hasta definir todos los casos. Prudente si el negocio necesita reglas internacionales ahora, pero quizá excesivo si no son necesarias para el siguiente Sprint.

Decisión: el equipo divide. Estima primero “guardar dirección nacional durante checkout” y deja “gestionar direcciones desde perfil” como historia posterior. La carta ? no bloqueó la sesión; evitó estimar una historia con dos productos dentro.

Errores comunes al gestionar la carta ?

Forzar consenso numérico. Si alguien vota ? y luego acepta un 5 solo para avanzar, no hay consenso: hay resignación.

Pedir explicaciones demasiado largas. El ? debe convertirse en una pregunta concreta, no en una revisión completa de arquitectura o producto.

Usar el ? como veto silencioso. También hay una responsabilidad de quien lo usa: formular la duda de forma accionable.

Hacer otra ronda sin cambiar nada. Si no se añadió contexto, la segunda votación solo mide cansancio o presión social.

Confundir incertidumbre normal con falta crítica. No toda incertidumbre impide estimar. En Agile no se elimina el cambio; se aprende a responder a él. La pregunta es si el equipo tiene contexto suficiente para comparar esta historia con otras ya conocidas.

Si usas una sala de planning poker online, puedes apoyarte en votación privada, revelado conjunto y nuevas rondas. En Stimo, por ejemplo, el organizador puede revelar resultados y abrir otra ronda según la guía de ayuda. Pero la práctica importante ocurre antes del clic: convertir la duda en decisión.

Conclusión práctica

La próxima vez que aparezca la carta ?, no la trates como una anomalía. Pregunta qué información falta y clasifícala: alcance, dependencia, riesgo o criterio de aceptación.

Después toma una decisión explícita:

• aclarar y votar de nuevo;
• dividir la historia;
• aplazar la estimación hasta tener contexto.

Un número obtenido sin entender la historia da sensación de avance, pero no mejora la planificación. Un ? bien usado puede ahorrar una mala decisión antes de que llegue al Sprint.

Fuentes consultadas

• Agile Manifesto: valores de colaboración, interacción y respuesta al cambio.
• Atlassian · Story points y estimación: estimación relativa, story points y planning poker.
• DORA Research: mejora continua y enfoque sociotécnico en equipos de software.
• Stimo · Ayuda: flujo de planning poker, votación privada, revisión de resultados y nuevas rondas.
• Stimo · FAQ: uso de la carta ?, cálculo y recomendaciones cuando hay dudas o dispersión.