Cómo establecer un objetivo de sprint (con ejemplos)
Un objetivo de sprint es una frase que explica por qué es importante el sprint. A continuación se explica qué caracteriza a un objetivo sólido, por qué debe preceder al alcance del proyecto y se ofrecen ejemplos comparativos de objetivos débiles y sólidos.
Un objetivo de sprint es una sola frase que explica por qué merece la pena realizar el sprint. Es el único resultado al que se compromete el equipo: aquello que será una realidad significativa cuando finalice el sprint. Todo lo que el equipo seleccione debe estar al servicio de ese objetivo y, cuando el sprint se complique, será el objetivo el que indique qué trabajo hay que proteger y cuál hay que descartar.
La mayoría de los equipos consideran el objetivo como un resumen de las tareas que han seleccionado. Eso es un error, y es la razón por la que tantos objetivos resultan inútiles.
El objetivo es lo primero, y la forma de alcanzarlo, lo segundo
Establezca el objetivo primero y, a continuación, elija las tareas que contribuyan a alcanzarlo. Un objetivo derivado a partir de una lista de tareas ya seleccionadas («entregar las tareas 4, 7 y 12») no es un objetivo, sino un índice. No le ayudará a tomar una decisión, ya que no refleja lo que realmente importa.
Lo fundamental es el orden. Cuando se acuerda el resultado antes de definir el alcance, la selección se convierte en una serie de preguntas sencillas: ¿nos acerca este elemento al objetivo? Si la respuesta es sí, inclúyalo. Si es no, más vale que haya una razón de peso —una corrección de seguridad, una dependencia imprescindible— o, de lo contrario, se pospone. Cuando se elige primero el alcance, todos los elementos parecen tener la misma importancia, y no hay nada que se pueda eliminar cuando el jueves se complica.
¿Qué aporta un objetivo sólido?
Un objetivo se justifica cuando cumple tres funciones:
- Se refiere a un resultado, no a una lista de tareas. «Los usuarios pueden restablecer su propia contraseña sin necesidad de ponerse en contacto con el servicio de asistencia» le indica qué ha cambiado en la situación. «Completar la épica de restablecimiento de contraseñas» le indica en qué tablero de Jira debe buscar.
- Le ayuda a establecer prioridades. La verdadera prueba de un objetivo es el último día del sprint, cuando no todo saldrá según lo previsto. Un buen objetivo le indica al instante qué debe priorizar. Si el objetivo es «permitir a los usuarios restablecer su contraseña», lanzará el flujo de restablecimiento y dejará de lado el rediseño del correo electrónico, que, aunque deseable, no es imprescindible. Si el objetivo es «terminar las incidencias», no tendrá una base sobre la que tomar decisiones, por lo que todo se retrasará un poco y nada se lanzará de forma impecable.
- El equipo debe poder expresarlo de memoria. Un objetivo que nadie puede recitar es un objetivo por el que nadie se guía. Si el equipo tiene que abrir el documento de planificación para recordar por qué está aquí, el objetivo es demasiado extenso o demasiado impreciso.
Objetivos débiles frente a objetivos sólidos
La diferencia entre un objetivo débil y uno sólido es, casi siempre, la diferencia entre definir una actividad y definir un resultado.
| Gol de poca calidad | Por qué falla | Un gol espectacular |
|---|---|---|
| «Trabajar en el rediseño de la caja». | Se refiere a un ámbito, no a un resultado. No hay meta. | «Un cliente habitual puede completar el proceso de pago en menos de un minuto desde el móvil». |
| «Cerrar 40 puntos de historia de la lista de tareas pendientes». | Un resultado debe estar al servicio del objetivo, no ser el objetivo en sí mismo. | «Resuma las tres razones principales por las que los clientes se ponen en contacto con el servicio de atención al cliente en relación con la facturación». |
| «Mejorar el rendimiento y corregir errores». | Dos objetivos, sin prioridades, sin posibilidad de elegir entre uno u otro. | «El panel de control se carga en menos de dos segundos en cuentas con más de 10 000 registros». |
| «Termine la función de generación de informes». | «Finalizar» oculta el alcance; ¿de quién es esa definición de «hecho»? | «Los responsables pueden exportar un informe semanal del equipo en formato PDF sin necesidad de nuestra ayuda». |
Observe que los objetivos sólidos comparten una estructura común: un usuario o sistema concreto, que realiza una acción concreta, según un estándar concreto. Se podría hacer una demostración de cada uno de ellos y todos los presentes estarían de acuerdo, sin discusión alguna, en si se ha cumplido o no.
Un objetivo, no varios
Fíjese un único objetivo. Un único objetivo es lo que hace posible las concesiones: si hay dos objetivos contrapuestos, no hay ningún principio que defender cuando se agota el tiempo, y se vuelve a la situación en la que «todo se descuida un poco».
Si el trabajo realmente no encaja en un único objetivo, considérelo una señal más que un problema que haya que pasar por alto. Por lo general, significa que el sprint está sobrecargado, o que se han fusionado dos líneas de trabajo en un solo sprint que resultaría más claro si se trataran como dos sprints distintos. En ocasiones, una pequeña cantidad de trabajo no relacionado, destinado a mantener el funcionamiento básico, se suma al objetivo; eso está bien, siempre y cuando todos sepan que se trata de un lastre, no de la misión.
¿A quién le corresponde el gol?
El responsable de producto aporta la intención: la razón empresarial por la que este sprint es más importante que las alternativas. Todo el equipo transforma esa intención en un objetivo con el que realmente pueda comprometerse, lo que significa que los desarrolladores deben creer que es factible con la capacidad disponible. Un objetivo en el que el equipo no cree es un deseo con una fecha límite.
Una vez que se cuenta con un objetivo por el que merezca la pena comprometerse, el resto de la planificación resulta más sencillo: la agenda lo utiliza como criterio para seleccionar el trabajo, y el scrum diario lo utiliza como referencia para medir el progreso. El objetivo fijado el lunes es el que guía al equipo durante todo el sprint.
Preguntas frecuentes
¿Qué es un objetivo de sprint?
El objetivo de un sprint es una sola frase que explica por qué merece la pena realizar dicho sprint: el único resultado al que se compromete el equipo. Se establece durante la planificación del sprint, antes de definir el alcance, y proporciona al equipo un objetivo común al que contribuyen los elementos seleccionados de la lista de tareas pendientes. Es la razón de ser del sprint, no una lista de las incidencias que lo componen.
¿Qué caracteriza a un buen objetivo de sprint?
Un buen objetivo de sprint define un resultado, no una lista de tareas; es lo suficientemente específico como para indicarle qué debe descartar cuando el sprint se complica; y todo el equipo puede expresarlo de memoria. Si su objetivo es simplemente «terminar estas incidencias», no le ayudará a tomar decisiones de priorización —que es precisamente la única función que tiene un objetivo—.
¿Quién establece el objetivo del sprint?
El responsable del producto aporta la intención —la razón empresarial por la que este sprint es importante— y todo el equipo la convierte en un objetivo con el que pueden comprometerse durante la planificación. Se trata de una colaboración, no de una orden. Los desarrolladores deben estar convencidos de que el objetivo es alcanzable con la capacidad disponible; de lo contrario, no pasa de ser un simple deseo.
¿Puede un sprint tener más de un objetivo?
Fíjese un único objetivo. Un único objetivo es lo que permite al equipo tomar decisiones difíciles bajo presión; con dos objetivos contrapuestos, no hay ningún principio que defender cuando el tiempo escasea. Si el trabajo se divide realmente en dos, suele ser una señal de que el sprint está intentando abarcar demasiado, o de que se ha fusionado el trabajo de dos equipos en un solo sprint.