Escribe un objetivo de sprint con el que tu equipo se comprometa de verdad
El objetivo de sprint es el compromiso más desaprovechado de Scrum. La Guía de Scrum nombra tres compromisos: el objetivo de producto para el Product Backlog, el objetivo de sprint para el Sprint Backlog y la definición de «terminado» para el Incremento. Sin embargo, muchos equipos tratan el objetivo de sprint como una ocurrencia tardía, garabateando algo vago después de haber elegido ya los elementos. Eso es al revés, y vacía en silencio el sprint de foco.
Un objetivo de sprint es una única meta para el sprint. Le da coherencia: una razón por la que el trabajo encaja entre sí, y una estrella polar por la que los Desarrolladores pueden guiarse cuando la realidad se entromete. En un 2022 de prioridades cambiantes y gente repartida entre casa y oficina, un objetivo claro es lo que evita que un equipo se convierta en una máquina de completar tareas sin saber por qué. Aquí tienes una lista de verificación para escribir uno digno de compromiso.
Cómo es un buen objetivo de sprint
Enuncia un resultado, no una lista de tareas. «Que los usuarios que regresan paguen una factura sin llamar a soporte» es un objetivo. «Terminar los tickets 412 al 419» es una lista de tareas disfrazada de objetivo.
Es único. Un sprint, un objetivo. Si necesitas la palabra «y» para unir dos metas sin relación, tienes dos objetivos y, probablemente, demasiado en el sprint.
Deja margen para negociar el alcance. El objetivo es fijo durante el sprint; los elementos exactos del backlog no lo son. Un buen objetivo permite a los Desarrolladores quitar o ajustar trabajo y aun así tener éxito, que es justo el sentido de comprometerse con un resultado y no con una lista.
Significa algo para un interesado. Alguien externo al equipo debería leerlo y entender por qué importa este sprint. Si solo los Desarrolladores pueden descifrarlo, es una nota técnica, no un objetivo.
Escríbelo durante la planificación, no después
La Guía de Scrum es clara: el objetivo de sprint se crea durante la planificación del sprint, y la conversación de planificación fluye a partir de él. El Product Owner propone cómo podría el producto aumentar su valor en este sprint; todo el Equipo Scrum colabora para elaborar el objetivo de sprint; luego los Desarrolladores seleccionan los elementos del backlog que lo entregarán y planifican cómo. El objetivo va primero y da forma a la selección, no al revés. Si te descubres redactando el objetivo para describir elementos que ya elegiste, detente e invierte el orden.
Una vía práctica: que el Product Owner plantee el problema o la oportunidad como una pregunta —«¿Qué haría de este sprint una victoria clara para el cliente?»— y redacta el objetivo como una sola frase que todo el equipo pueda decir en voz alta. Ponedlo a prueba juntos antes de elegir los elementos.
Úsalo todo el sprint, o fue teatro
Lee el objetivo de sprint en voz alta al comienzo de cada Daily Scrum: existe precisamente para enfocar hacia él el plan diario de los Desarrolladores.
Cuando aparezca trabajo nuevo a mitad del sprint, pregunta si sirve al objetivo antes de dejarlo entrar.
Si el objetivo queda obsoleto porque la situación cambió, el Product Owner puede cancelar el sprint, algo raro, pero es el objetivo lo que hace posible ese juicio.
En la Sprint Review, habla primero del objetivo y después del número de elementos. ¿Lograsteis el resultado con el que os comprometisteis?
Un objetivo de sprint que escribes al inicio, dices cada mañana y por el que os juzgáis al final convierte una lista de tickets en un sprint con sentido. Esa es la diferencia entre un equipo ocupado y un equipo que entrega valor.
Si quieres afinar cómo tus equipos planifican y entregan cada sprint, la asesoría de ejecución de programas y proyectos de XNM puede ayudarte a construir los hábitos que hacen que lo ágil se sostenga.