En este artículo, Dave West, director general de Scrum.org, resume el protocolo de planificación de sprints tal y como se describe en Scrum.org. Scrum.org enseña scrum basándose en la guía de la metodología scrum, que se considera la guía oficial para el marco de trabajo scrum en el mundo de la metodología ágil. A continuación, Megan Cook, responsable de producto de Jira, habla de su visión sobre la planificación de sprints en este vídeo:
¿Qué es la planificación de sprints?
La planificación de sprints es un evento en scrum que inicia el sprint. El objetivo de la planificación de sprints es definir lo que se puede entregar en el sprint y cómo se conseguirá ese trabajo. La planificación de sprints se hace en colaboración con todo el equipo de scrum.
En scrum, el sprint es un periodo definido de tiempo en el que se hace todo el trabajo. Sin embargo, antes de poder ponerte manos a la obra tienes que preparar el sprint. Tienes que decidir cuánto tiempo va a durar, el objetivo del sprint y por dónde vas a empezar. La sesión de planificación de sprints inicia el sprint definiendo el orden del día y el punto de atención. Si se hace correctamente, también crea un entorno en el que el equipo está motivado, se siente retado y puede triunfar. Las malas planificaciones de sprints pueden fastidiar al equipo al definir expectativas no realistas.
- El qué: el propietario del producto describe el objetivo (o propósito) del sprint y qué elementos del backlog contribuyen a dicho objetivo. El equipo de scrum decide qué se puede hacer en el próximo sprint y qué hará durante el sprint para conseguirlo.
- El cómo: el equipo de desarrollo planifica el trabajo necesario para alcanzar el objetivo del sprint. En última instancia, el plan del sprint resultante es una negociación entre el equipo de desarrollo y el propietario del producto en función del valor y el esfuerzo.
- El quién: no puedes planificar sprints sin el propietario del producto ni el equipo de desarrollo. El propietario del producto define el objetivo en función del valor que busca. El equipo de desarrollo tiene que entender cómo puede o no puede alcanzar dicho objetivo. Si alguno de los dos no está en este evento, la planificación del sprint será casi imposible.
- Los elementos de trabajo: un buen punto de partida para el plan del sprint es el backlog del producto, ya que proporciona una lista de “cosas” que posiblemente podrían formar parte del sprint actual. Además, el equipo debería analizar el trabajo realizado en el incremento y tener visión de la capacidad.
- El resultado: el resultado más importante de la reunión de planificación de sprints es que el equipo pueda describir el objetivo del sprint y cómo empezará a trabajar hacia ese objetivo. Esto se refleja en el backlog de sprint.
Preparación de la reunión de planificación de sprints
Organizar un gran evento de planificación de sprints requiere un poco de disciplina. El propietario del producto debe estar preparado, combinando las lecciones de la revisión del sprint anterior, los comentarios de las partes interesadas y su visión del producto, para allanar el terreno del sprint. Por motivos de transparencia, el backlog del producto debería estar actualizado y perfeccionado para ofrecer claridad. La mejora del backlog es un evento opcional en scrum, porque algunos backlogs no lo requieren. Sin embargo, para la mayoría de los equipos, es mejor reunir al equipo para revisar y perfeccionar el backlog antes de la planificación de sprints.
Si tienes un sprint de dos semanas, organiza una reunión de mejora del backlog a mitad del sprint. Al equipo le viene muy bien distanciarse del sprint y mirar qué viene a continuación. Eso no solo ayuda a prepararse para la planificación de sprints, sino que también puede darle otra perspectiva al trabajo actual.
Definición de un límite de tiempo para la planificación de sprints
La planificación de sprints debería limitarse a no más de dos horas por cada semana del sprint. Así, por ejemplo, la reunión de planificación de sprints de un sprint de dos semanas no debería durar más de cuatro horas. Esto se llama “fijar el tiempo máximo” o establecer una cantidad máxima de tiempo para que el equipo termine una tarea, en este caso, planificar el sprint. El experto en scrum es el responsable de que se entienda el tiempo máximo. Si el equipo está satisfecho antes de que haya terminado el tiempo máximo, entonces el evento ha terminado. Hay un tiempo máximo permitido, pero no hay un tiempo mínimo.
Céntrate en los resultados, no en el trabajo
Durante la planificación de sprints, es fácil “empantanarse” en el trabajo centrándose en qué tarea debería ir primero, quién debería hacerla y cuánto tiempo llevará. Para el trabajo complejo, el nivel de información que sabes al principio puede ser bajo y la mayor parte se basa en suposiciones. Scrum es un proceso empírico, lo que significa que no puedes planificar por adelantado, sino más bien aprender con la práctica, y después volver a incorporar esa información al proceso.
El objetivo del sprint describe el propósito del sprint en términos generales, pero los elementos del backlog también pueden escribirse con un resultado en mente. Las historias de usuario son una forma estupenda de describir el trabajo desde el punto de vista de un cliente. Las historias de usuario, escritas como la de abajo, reorientan los defectos, las incidencias y las mejoras hacia el resultado que el cliente está buscando en vez de hacia el problema observado.
Al añadir resultados claros y cuantificables a la historia de usuario, los resultados se pueden cuantificar claramente y sabes cuando has terminado. Asimismo, al disponer del máximo posible de claridad del trabajo en el que se está centrando el equipo por adelantado, todos tienen la transparencia necesaria para ponerse manos a la obra. Por ejemplo, dejar una cosa poco precisa es mucho peor que describir algo como una pregunta que se tiene que responder durante el sprint.
No saber algo es diferente de ser poco preciso. No ignores lo desconocido: es la realidad de los trabajos complicados. Pero tampoco los ocultes usando palabras poco precisas. En su lugar, sé claro cuando no sepas algo y enmarca el trabajo en términos de entender algo.
Las estimaciones son necesarias, pero no pretendas que sabes más de lo que en realidad sabes
La planificación de sprints requiere cierto nivel de estimación. El equipo tiene que definir lo que puede o no puede hacerse en el sprint: esfuerzo estimado frente a capacidad. A menudo, se confunde la estimación con los compromisos. Las estimaciones son por su propia naturaleza previsiones que se basan en el conocimiento con el que se cuenta. Técnicas como los puntos de historia o las tallas de camisetas añaden valor al proceso dándole al equipo una forma diferente de encarar el problema. Sin embargo, no son herramientas mágicas con las que descubrir la verdad absoluta, cuando esta no existe. Cuanto más cosas no se sepan, menos probable será que la estimación sea correcta.
Una buena estimación requiere un entorno basado en la confianza donde la información se proporcione libremente y las suposiciones se discutan en busca de aprendizaje y mejora. Si las estimaciones se utilizan de una forma negativa y confrontacional una vez que se ha terminado el trabajo, es probable que las futuras estimaciones sean mucho superiores para asegurarse de que no vuelven a estar mal nunca más o el tiempo necesario para crearlas sea mucho mayor, ya que el equipo se lo pensará dos veces preocupado por las consecuencias de que estén mal.
Prueba a utilizar diferentes técnicas de estimación como las tallas de camisetas o los puntos de historia. Diferentes técnicas podrían proporcionar diferentes visiones del problema.
Prácticas recomendadas de la planificación de sprints
Es fácil empantanarse tanto con los detalles de la planificación de sprints que te olvidas de que el objetivo de esta es crear un plan "suficientemente bueno" para el siguiente sprint. Ese plan no debería convertirse en un problema para el equipo, sino que debería orientar al equipo hacia resultados valiosos y permitir protecciones para la autoorganización. Un buen plan de sprint motiva a todo el mundo al definir un resultado y un plan claro para el éxito. Sin embargo, ten cuidado y no planifiques con demasiada antelación. En vez de crear el plan de sprint más completo "en el que se refleje cada minuto del sprint", céntrate en el objetivo y crea lo suficiente del backlog de sprint para comenzar. A continuación, asegúrate de que el backlog del producto esté ordenado para que el equipo pueda asumir trabajo si han alcanzado el objetivo del sprint de manera anticipada.
Scrum es un marco de trabajo compuesto de procesos que pretende solucionar problemas complejos. Los problemas complejos requieren un proceso empírico (aprender con la práctica). Los procesos empíricos son muy difíciles de planificar, así que no te engañes a ti mismo: no puedes crear el plan perfecto. En su lugar, céntrate en los resultados y avanza. No tiene por qué ser complicado, incluso aunque el problema que estás resolviendo lo sea.
¿Todo listo para empezar? Aprende a utilizar sprints en Jira
Planifica el sprint perfecto con la plantilla de scrum de Jira
Divide los proyectos grandes en tareas e hitos manejables a través de los sprints.
