Por qué tantos objetivos de Sprint no sirven — y cómo escribir uno que sí
A mediados de 2021, muchos equipos Scrum llevaban más de un año trabajando separados — entre cocinas, cuartos improvisados y conexiones poco fiables, mientras los problemas de suministro cambiaban constantemente lo que siquiera era posible construir. En ese escenario, un objetivo de Sprint débil deja de ser una molestia menor. Cuando nadie puede asomarse al escritorio del compañero para preguntar qué importa de verdad este Sprint, el objetivo es uno de los pocos hilos que mantienen un propósito común. Si no dice nada, el Sprint se desvía.
La Guía de Scrum es clara: el objetivo de Sprint es el único objetivo del Sprint, creado por todo el Equipo Scrum durante la Planificación del Sprint. Debe dar a los Desarrolladores margen para decidir cómo cumplirlo y dar a todos una razón para coordinarse en lugar de perseguir cada uno su propia lista de tareas. El problema es que la mayoría escribe algo que parece un objetivo pero no hace nada de eso.
Los errores que vacían de sentido a un objetivo de Sprint
Enumerar el backlog en vez de enunciar un objetivo. «Terminar las historias 412, 415 y 419» no es un objetivo de Sprint, es una lista. No ofrece forma de negociar cuando un elemento resulta más difícil de lo previsto. Un objetivo real permite descartar o reformular elementos y aun así tener éxito.
Escribirlo sobre la producción y no sobre el resultado. «Construir el botón de exportación» dice qué hacer, nunca por qué. «Que finanzas pueda sacar un informe de cierre de mes sin llamar a soporte» dice cómo se ve el éxito, y deja hallar el camino más simple.
Hacerlo tan amplio que no quepa en un Sprint. «Mejorar la experiencia de pago» es un tema, no un objetivo. Si en la Revisión no pudieras decir con honestidad si lo lograste, es demasiado vago para comprometerse.
Fijarlo después de planificar el trabajo. Cuando el objetivo se reconstruye a partir de las historias ya elegidas, deja de guiar nada. El objetivo debe orientar la selección, no resumirla.
Dejar que el Product Owner lo imponga solo. El Product Owner propone el objetivo de negocio, pero el objetivo se forja con los Desarrolladores, que saben qué es viable. Un objetivo impuesto sin esa conversación rara vez sobrevive al contacto con el trabajo.
Cómo escribir uno digno de compromiso
Parte del objetivo de Producto y hazte una pregunta sencilla: si este Sprint sale bien, ¿qué pasará a ser cierto que antes no lo era? Formula la respuesta como un único resultado que entendería una parte interesada no técnica. Luego contrástalo con el trabajo — si el equipo no ve un camino creíble, estréchalo hasta que lo vea.
Enuncia un solo objetivo, no tres — un Sprint tiene un único objetivo de Sprint.
Hazlo comprobable: en la Revisión deberías poder decir con claridad si se cumplió.
Deja a los Desarrolladores elegir el cómo, para que se adapten a mitad de Sprint.
Colócalo bien visible, sobre todo en un equipo remoto — repítelo en el Daily Scrum.
Buena prueba para un equipo híbrido o distribuido: ¿el objetivo seguiría teniendo sentido leído en voz alta en una videollamada a alguien que faltó a la planificación? Si solo tiene sentido junto al tablero, es un resumen del backlog disfrazado de objetivo. El propósito del objetivo es permitir actuar de forma coherente cuando no puedes consultarte sin parar — que, en 2021, era casi siempre.
Por último, trata el objetivo de Sprint como un compromiso con el Incremento, no como un contrato de alcance fijo. Los Desarrolladores pueden negociar el alcance con el Product Owner a medida que aprenden, pero el objetivo se mantiene firme. Esa estabilidad es justo lo que permite a un equipo recortar con criterio bajo presión en lugar de prometer de más o abandonar en silencio el sentido del Sprint.
Ayudar a los equipos de entrega a fijar objetivos que de verdad orienten el trabajo — y lo conecten con los resultados que importan a los líderes — es el día a día de la asesoría de entrega de programas y proyectos de XNM.