Semáforo de estimabilidad: decide si una historia merece planning poker

Llegar al refinamiento con historias pequeñas no garantiza que estén listas para estimarse. Una historia puede parecer manejable y, aun así, esconder una decisión de producto, una dependencia técnica o un criterio de aceptación demasiado abierto. El problema aparece cuando el equipo intenta resolver esa incertidumbre con un número.

En ese punto, el planning poker deja de ser una ayuda y se convierte en una negociación incómoda: alguien propone un punto medio, otra persona advierte un riesgo, otra vota alto por prudencia y la conversación se alarga sin aclarar qué falta. La salida no es votar más rápido. Es decidir antes si la historia merece una estimación.

La idea es coherente con dos principios prácticos de la agilidad: favorecer las interacciones y la colaboración por encima del proceso rígido, como recoge el Agile Manifesto, y usar la estimación relativa para comparar esfuerzo y complejidad, no para fabricar una precisión que el equipo no tiene. Atlassian explica el uso de story points y planning poker como una práctica de estimación relativa y calibración, no como una predicción exacta de horas (Atlassian).

Esta guía propone un artefacto sencillo: un semáforo de estimabilidad. Sirve para decidir, antes de votar o antes de revelar votos, si conviene estimar, aclarar, dividir o aplazar.

El error: discutir el número cuando falta la historia

Cuando una estimación se atasca, el desacuerdo visible suele estar en los puntos. Pero la causa real puede estar antes: el equipo no está estimando la misma cosa.

Señales típicas:

• Una persona está pensando en la interfaz y otra en cambios de datos.
• QA pregunta por escenarios límite que no aparecen en la historia.
• Desarrollo asume una integración que Producto no había considerado.
• UX no sabe si el flujo actual se mantiene o se rediseña.
• El equipo necesita varios minutos de explicación oral para entender qué se pide.

Ninguna de estas señales significa que el equipo esté estimando mal. Puede significar que está detectando información insuficiente. Y eso es valioso si se usa para tomar una decisión.

La pregunta útil no es: «¿Qué número ponemos para cerrar?». La pregunta útil es: «¿Tenemos suficiente entendimiento compartido para que un número ayude?». Si la respuesta es no, estimar en ese momento solo maquilla el riesgo.

El semáforo de estimabilidad

Antes de iniciar la ronda, o justo antes de revelar votos, el facilitador puede hacer una pausa de dos minutos. No para reescribir toda la historia, sino para clasificarla con criterios explícitos.

Color	Señal	Decisión recomendada
Verde	Alcance, criterios y dependencias están claros para quienes estiman	Votar y cerrar la estimación si no aparece una duda nueva
Ámbar	Hay una o dos dudas concretas que pueden resolverse en la sesión	Aclarar primero, actualizar la historia y votar después
Rojo	El equipo no comparte alcance, hay decisiones pendientes o la historia mezcla trabajos distintos	No estimar todavía: dividir, investigar o aplazar

Este semáforo evita dos extremos. Por un lado, no convierte cada duda en una excusa para posponer. Por otro, evita cerrar historias mal entendidas con un número tranquilizador.

La clave es que el color no lo decide la persona más senior ni quien tiene más prisa. Lo decide el equipo con base en evidencias visibles: criterios de aceptación, límites de alcance, dependencias, riesgos y ejemplos de comportamiento esperado.

Las cinco preguntas mínimas antes de votar

Un equipo no necesita una plantilla enorme para estimar mejor. Necesita confirmar lo esencial. Estas cinco preguntas funcionan como una puerta de entrada:

1. ¿Qué cambio observable recibirá el usuario o el sistema? Si no puede describirse en una frase, quizá la historia aún está formulada como intención amplia.
2. ¿Qué queda fuera del alcance? La estimación mejora cuando el equipo sabe qué no debe incluir.
3. ¿Qué criterios de aceptación deben cumplirse para darla por terminada? No tienen que ser perfectos, pero sí suficientes para orientar desarrollo, prueba y revisión.
4. ¿Qué dependencia puede bloquear o cambiar el tamaño? API externa, diseño pendiente, dato no disponible, decisión legal, entorno de prueba o revisión de otra área.
5. ¿Qué duda, si se resuelve ahora, cambiaría la estimación? Esta pregunta separa curiosidades de incertidumbres relevantes.

Si el equipo responde con claridad, la historia está en verde. Si una o dos respuestas requieren aclaración rápida, está en ámbar. Si las respuestas abren una conversación amplia, está en rojo.

En herramientas de planning poker como Stimo, la ayuda documenta un flujo de votos privados, revelado por el organizador y posibilidad de abrir otra ronda cuando cambia el entendimiento. También contempla el uso de la duda cuando falta información. Eso no sustituye la conversación; la hace visible y ordenada. Si usas otra herramienta, el principio es el mismo: primero decide si hay contexto suficiente, luego vota.

Cuándo dividir, aclarar o aplazar

No todas las historias ambiguas necesitan la misma respuesta. Una decisión madura distingue entre tres movimientos.

Aclara cuando la incertidumbre es pequeña y resoluble en la sesión. Por ejemplo: falta confirmar si el mensaje de error debe aparecer en pantalla o en email. Si el Product Owner puede responder y el equipo actualiza el criterio de aceptación, se puede votar después.

Divide cuando la historia mezcla resultados distintos o perfiles de trabajo que no dependen unos de otros. Por ejemplo: «Como usuario quiero gestionar mis notificaciones» puede incluir activar canales, editar preferencias, validar permisos y registrar auditoría. Si cada parte aporta valor o aprendizaje por separado, estimarlas juntas puede ocultar complejidad.

Aplaza cuando falta una decisión externa o una investigación previa. Por ejemplo: no se sabe si la integración permite cierto dato, o el equipo necesita validar rendimiento antes de comprometer un enfoque. En ese caso, estimar la historia completa puede dar una falsa sensación de preparación. Una alternativa es crear una tarea de investigación acotada y volver con información.

Un criterio útil: si la conversación necesaria para estimar produce cambios en alcance, criterios o solución, no era una conversación de estimación; era una conversación de refinamiento. No pasa nada. Solo conviene nombrarla bien.

Ejemplo trabajado: del número forzado a una decisión útil

Ejemplo hipotético: un equipo va a estimar esta historia: «Como cliente, quiero descargar mis facturas para guardarlas».

Al principio parece pequeña. Alguien propone votarla rápido. Antes de abrir la ronda, la Scrum Master aplica el semáforo.

Preguntas mínimas:

• Cambio observable: el cliente puede descargar facturas desde su área privada.
• Fuera de alcance: no se enviarán facturas por email en esta historia.
• Criterios: debe verse una lista y poder descargar PDF.
• Dependencias: no está claro si el PDF ya existe o debe generarse.
• Duda que cambia la estimación: si hay que generar el PDF desde datos fiscales, el trabajo es mucho mayor.

La historia pasa de verde aparente a ámbar. El Product Owner aclara que, para esta primera versión, los PDF ya existen en un repositorio interno y solo hay que exponerlos al cliente autenticado. El equipo añade ese límite al criterio de aceptación: «Solo facturas con PDF ya generado; si no existe, mostrar estado no disponible».

Ahora la historia vuelve a verde y el planning poker sí aporta. Si, en cambio, nadie pudiera confirmar de dónde sale el PDF, la decisión correcta sería no estimar todavía o dividir: una historia para listar facturas existentes y una investigación para generación de PDF.

La mejora no está en haber elegido menos puntos. Está en haber evitado que dos personas estimaran problemas distintos.

Límites y errores comunes

El semáforo de estimabilidad también puede usarse mal. Estos son los riesgos más frecuentes:

• Convertirlo en burocracia. Si la pausa tarda más que la conversación útil, simplifica. Cinco preguntas bastan.
• Exigir certeza total. Agile no busca eliminar todo cambio futuro. Busca tomar decisiones con suficiente información y capacidad de adaptación.
• Usar el rojo como bloqueo automático. Una historia roja debe terminar con una acción: dividir, investigar, pedir una decisión o reescribir criterios.
• Confundir tamaño con falta de contexto. Una historia puede ser grande pero clara; aun así quizá convenga dividirla por flujo de valor. Otra puede ser pequeña pero ambigua.
• Dejar que Producto o arquitectura decidan solos. La estimabilidad es una propiedad compartida: incluye producto, desarrollo, QA, UX y cualquier perfil que aporte contexto real.

Si el equipo usa salas temporales, perfiles o roles diferenciados, conviene revisar cómo participa cada persona. La FAQ de Stimo explica que ciertos perfiles pueden observar por defecto para reducir sesgos en la estimación, mientras participan en la conversación y aclaran contexto. La práctica trasladable es separar aclarar de votar: quien aporta contexto ayuda a entender; quien estima esfuerzo aporta el número.

Cierre práctico

La próxima vez que una historia genere una discusión larga, no empieces preguntando quién tiene razón. Pregunta qué color tiene.

Verde: estimad. Ámbar: aclarad la duda que cambia la estimación y votad después. Rojo: no disfracéis incertidumbre con puntos; dividid, investigad o aplazad.

El planning poker funciona mejor cuando el equipo lo usa como detector de entendimiento compartido. El número es útil solo después de esa conversación.

Fuentes consultadas

• Agile Manifesto: valores de colaboración, interacción y adaptación al cambio.
• Atlassian · Story points y estimación: estimación relativa, story points y planning poker.
• Stimo · ayuda: flujo documentado de votación privada, revelado de resultados y nuevas rondas.
• Stimo · preguntas frecuentes: roles, participación y uso básico de salas de planning poker.