La señal de alerta es fácil de pasar por alto si no se busca. Un equipo termina su reunión de planificación del sprint. Se estiman las historias, se completa el tablero, el objetivo del sprint está escrito en un lugar visible. Todo parece ordenado. Dos semanas después, el equipo está en la segunda semana del sprint y alguien plantea una pregunta que debería haberse respondido en la planificación. La conversación se vuelve tensa. El propietario del producto dice una variación de “pero dijiste que harías X1”, y el equipo explica que en realidad están haciendo X2. Lo que sigue no es una conversación sobre si X2 todavía cumple el propósito del sprint. Lo que sigue es una discusión sobre el alcance.
Esto no se debe a un fallo de comunicación. Es síntoma de una incomprensión más profunda sobre el objetivo de la planificación del sprint. Y ocurre con más frecuencia de lo que la mayoría de los equipos creen.
Las tres C y lo que realmente significan
Las historias de usuario nunca fueron concebidas como especificaciones. La formulación original —Tarjeta, Conversación, Confirmación— describe un proceso, no un contrato. La tarjeta es un marcador. La conversación es donde se desarrolla la comprensión. La confirmación es la forma en que el equipo sabe cuándo el trabajo está terminado. Las tres son importantes, pero la del medio es donde la mayoría de los equipos pierden el hilo.
He observado que los equipos tratan la tarjeta como si estuviera completa. Redactan los criterios de aceptación, estiman la complejidad y se comprometen con el trabajo. Todo esto es útil. Pero en algún momento, la tarjeta deja de ser un estímulo para la conversación y pasa a ser un acuerdo vinculante. Cuando ese cambio ocurre —a menudo de forma silenciosa, a menudo sin que nadie se dé cuenta— la planificación del sprint deja de funcionar como debería.
Cuando las historias se convierten en contratos
El cambio es visible en cómo los equipos hablan de su trabajo a mitad del sprint. Si el dueño del producto dice “pero dijiste que harías X1” y el equipo se pone a la defensiva, es una señal. Sugiere que la historia se entendió como un contrato durante la planificación, y cualquier desviación de lo escrito se percibe como un incumplimiento.
El problema no es que el equipo cambiara de rumbo. Las metodologías ágiles se diseñaron para facilitar el aprendizaje y la adaptación. El problema es que la base de esa adaptación —una comprensión compartida de lo que importa y por qué— nunca se estableció desde el principio. El equipo se comprometió a entregar X1 porque así lo estipulaba la estrategia. No se comprometieron con el resultado que X1 debía producir, porque ese resultado nunca se explícito.
Cuando trabajo con equipos que siguen este patrón, las reuniones de planificación suelen ser similares. Se leen historias en voz alta. Se hacen preguntas sobre la implementación técnica. Se discuten estimaciones. Todos asienten. Pero la conversación se centra en el alcance (qué se construirá) en lugar de la intención (por qué es importante y cómo se ve el éxito). La reunión termina con claridad sobre los resultados y muy poca claridad sobre el propósito.
Planificación basada en el valor, no en el alcance
La alternativa no es planificar con menos rigor. Es planificar de forma diferente. Una reunión de planificación de sprint funcional no se limita a “¿qué estamos construyendo?”. Enfoca la conversación en lo que a veces llamo el objetivo cualitativo del sprint: el resultado o valor que el equipo busca alcanzar, independientemente del alcance específico que pueda alcanzarlo.
El objetivo cualitativo no es “estamos completando 45 puntos de historia”. Es “estamos permitiendo a los usuarios gestionar sus suscripciones sin contactar con soporte”, “estamos reduciendo la fricción en la incorporación de nuevos clientes” o “estamos estabilizando el proceso de pago para que los errores se reduzcan por debajo del 2%”. Las historias específicas del sprint son una hipótesis sobre cómo lograr ese objetivo. No constituyen el objetivo en sí.
Cuando el objetivo cualitativo está claro, la conversación a mitad del sprint cambia. En lugar de “pero dijiste que harías X1”, el dueño del producto puede preguntar: “¿Estás haciendo X2 en lugar de X1? ¿Cómo afecta eso al objetivo cualitativo del sprint?”. Esta pregunta replantea la discusión. Hace que el equipo deje de defender su desviación de la tarjeta y se centre en evaluar si el trabajo que están realizando sigue cumpliendo el propósito acordado.
Cómo es una buena planificación
Una buena planificación no elimina las sorpresas. El desarrollo de software es demasiado complejo para eso. Lo que sí hace una buena planificación es crear las condiciones para que las sorpresas se gestionen de forma productiva. Esto requiere más que un backlog compartido y una declaración de objetivos del sprint. Requiere un entendimiento compartido.
El entendimiento compartido se desarrolla mediante la conversación. No se trata de qué se construirá, sino de por qué es importante, a quién beneficia, cómo se ve el éxito y qué compensaciones son aceptables si las cosas no salen como se espera. Esas conversaciones toman tiempo. En el momento parecen ineficientes. Pero marcan la diferencia entre un equipo capaz de adaptarse inteligentemente a mitad del sprint y un equipo que se fragmenta en discusiones sobre el alcance cuando la realidad se desvía del plan.
He observado reuniones de planificación donde el propietario del producto y el equipo dedican quince minutos a una sola historia, no porque sea compleja, sino porque trabajan para asegurar que todos comprendan lo mismo. Analizan casos extremos. Explican qué significa “terminado” en la práctica. Aclaran qué es esencial y qué es flexible. Para cuando se estima la historia, el equipo ha construido un modelo mental del trabajo lo suficientemente detallado como para gestionar imprevistos.
Estos equipos rara vez discuten sobre el alcance a mitad del sprint. Cuando se desvían de la tarjeta, lo hacen deliberadamente y pueden explicar por qué la desviación sigue siendo útil para el propósito del sprint. La conversación se mantiene colaborativa en lugar de conflictiva, porque las bases se sentaron en la planificación.
El costo de una planificación superficial
Una planificación superficial parece eficiente. Las historias se revisan rápidamente. Se asignan estimaciones. La reunión termina a tiempo. Pero el coste aparece más tarde, en la segunda semana del sprint, cuando alguien se da cuenta de que se omitió una dependencia, una suposición errónea o que los criterios de aceptación no reflejan realmente las necesidades del propietario del producto.
En ese momento, el equipo tiene tres opciones. Pueden entregar lo escrito en la tarjeta, incluso si ya no tiene sentido. Pueden renegociar el alcance, a menudo en una conversación tensa que se asemeja a una disputa contractual. O pueden adaptar el trabajo para que cumpla el propósito del sprint, si este quedó suficientemente claro como para guiar la decisión.
La tercera opción solo está disponible para equipos que planificaron pensando en el valor en lugar del alcance. Y esa distinción —entre planificar lo que se construirá y planificar lo que se logrará— marca la diferencia entre una planificación de sprints que funciona y una planificación de sprints que genera fricción.
Avanzando
Si su equipo se encuentra en discusiones sobre el alcance durante el sprint, el problema no es que las personas sean difíciles ni que los requisitos cambien con demasiada frecuencia. El problema es que la planificación del sprint no estableció el entendimiento compartido necesario para que la adaptación se desarrollara sin problemas. Las historias se trataron como contratos en lugar de como puntos de partida, y el objetivo cualitativo, si es que existía, no era lo suficientemente claro ni convincente como para guiar las decisiones cuando el plan se desviaba de la realidad.
Solucionar esto no requiere un nuevo marco ni un conjunto diferente de ceremonias. Requiere un cambio en el propósito de la planificación del sprint. No para asegurar entregas, sino para construir un entendimiento compartido. No para crear contratos, sino para establecer intenciones. No para predecir el futuro, sino para preparar al equipo para gestionar la incertidumbre juntos.
Ese cambio lleva tiempo. Alarga las reuniones de planificación a corto plazo. Pero facilita la fluidez de los sprints y cambia el carácter de las conversaciones que los equipos mantienen cuando las cosas no salen como se esperaba. En lugar de discusiones sobre lo prometido, se dialoga sobre lo que aún importa. Y eso es lo que siempre se pretendió lograr con la planificación de sprints.
Si bien los principios aquí descritos son sencillos, pasar de la planificación basada en el alcance a la basada en el valor a menudo requiere una perspectiva externa al sistema para detectar dónde fallan las conversaciones. Exploremos cómo planificar para la intención en lugar de los resultados puede funcionar para tu equipo. Reserva una consulta gratuita para hablar sobre los desafíos específicos de planificación de tu equipo y convirtamos tu planificación de sprints en una verdadera alineación.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
