Redactar un objetivo de sprint que valga la pena comprometerse a cumplir
Muchos equipos Scrum tratan el objetivo de sprint como papeleo — una frase escrita tras la planificación para rellenar un campo en la herramienta. Es una oportunidad perdida. La Guía Scrum describe el objetivo de sprint como el único propósito del sprint, parte del Sprint Backlog, que da a los Desarrolladores una finalidad compartida y la flexibilidad para decidir cómo llegar a ella. Bien redactado, es la frase más útil de su sprint.
La distinción que conviene retener: un objetivo de sprint describe un resultado, no una lista de entregables. «Terminar los tickets 412 al 419» no es un objetivo; es una lista de tareas. «Permitir que un cliente recurrente repita una compra anterior en menos de un minuto» sí es un objetivo, porque le dice al equipo cómo se ve el éxito y le permite ajustar el trabajo si la realidad cambia a mitad del sprint.
De dónde sale el objetivo
El objetivo de sprint se elabora durante la planificación, en conversación, no se impone desde arriba. El Product Owner trae lo más valioso a perseguir a continuación; los Desarrolladores discuten qué es factible según la capacidad. El objetivo surge de esa negociación. A comienzos de 2021, cuando muchas de estas conversaciones ocurren por video, el objetivo trabaja de más — mantiene alineado a un equipo distribuido cuando nadie puede asomarse a la sala para ver qué construyen los demás.
Ponga su borrador a prueba con tres preguntas
¿Es un resultado? ¿Describe un cambio en el producto o un valor entregado, en vez de un recuento de tareas terminadas? Si pudiera cumplirlo terminando elementos distintos a los planeados, es un objetivo de verdad.
¿Está enfocado? Un único objetivo coherente, no tres sin relación grapados juntos. Si necesita la palabra «y» dos veces, probablemente tiene varios objetivos compitiendo por el sprint.
¿Guía las concesiones? Cuando aparece algo inesperado a mitad del sprint, ¿puede el equipo usar el objetivo para decidir qué soltar y qué proteger? Un objetivo que no puede zanjar una discusión no está cumpliendo su función.
Una prueba útil: imagine que una dependencia se retrasa y dos elementos del backlog se vuelven imposibles. ¿Puede el equipo aun así cumplir el objetivo de sprint reformulando el trabajo restante? Si la respuesta es sí, escribió un resultado. Si el objetivo se derrumba en cuanto se retrasa un solo elemento, escribió una lista de tareas disfrazada.
Manténgalo vivo durante todo el sprint
Mencione el objetivo en el Daily Scrum — la pregunta es el avance hacia el objetivo, no el estado de cada ticket.
Úselo para decir que no: el alcance que no sirve al objetivo suele poder esperar.
Si el objetivo queda obsoleto porque el mundo cambió, eso es una conversación con el Product Owner sobre el sprint, no un abandono silencioso.
Revíselo con honestidad en la Revisión de Sprint: ¿logramos el resultado, sin importar cuántos elementos se cerraron?
Un objetivo de sprint sólido convierte un backlog en una misión. Da al equipo permiso para ser ingenioso sobre cómo alcanzar el objetivo, y ofrece a las partes interesadas algo significativo que inspeccionar. Invierta los diez minutos de la planificación en plantearlo bien; se paga solo cada día del sprint.
Si sus equipos hacen Scrum pero les cuesta que los sprints sumen resultados, la asesoría en entrega de programas y proyectos de XNM puede ayudarle a ajustar la cadencia.