Planificación del Sprint

La planificación del sprint es un evento en scrum que inicia el sprint. El propósito de la planificación del sprint es definir qué se puede entregar en el sprint y cómo se logrará ese trabajo. La planificación del sprint se realiza en colaboración con todo el equipo de scrum.

A diferencia del deporte, scrum te alienta a estar siempre corriendo para que puedas entregar un software que funcione, mientras aprendes y mejoras continuamente.

En scrum, el sprint es un período de tiempo establecido en el que se realiza todo el trabajo. Sin embargo, antes de que puedas entrar en acción, debes configurar el sprint. Debes decidir cuánto tiempo va a durar el cuadro de tiempo, el objetivo del sprint y dónde comenzará. La sesión de planificación del sprint inicia el sprint estableciendo la agenda y el enfoque. Si se hace correctamente, también crea un entorno en el que el equipo está motivado, desafiado y puede tener éxito. Los malos planes de sprint pueden descarrilar al equipo al establecer expectativas poco realistas.

• El qué - El product owner describe el objetivo (o meta) del sprint y qué elementos del backlog contribuyen a ese objetivo. El equipo de scrum decide qué se puede hacer en el próximo sprint y qué harán durante el sprint para que eso suceda.
• El cómo - El equipo de desarrollo planifica el trabajo necesario para lograr el objetivo del sprint. En última instancia, el plan de sprint resultante es una negociación entre el equipo de desarrollo y el producto owner basada en el valor y el esfuerzo.
• El quién - No se puede hacer una planificación del sprint sin el Product Owner o el equipo de desarrollo. El product owner define el objetivo en función del valor que buscan. El equipo de desarrollo debe comprender cómo pueden o no pueden cumplir ese objetivo. Si alguno de los dos falta en este evento, la planificación del sprint es casi imposible.
• Las entradas - Un gran punto de partida para el plan del sprint es el product backlog, ya que proporciona una lista de “cosas” que podrían formar parte del sprint actual. El equipo también debe observar el trabajo existente realizado en el incremento y tener en cuenta la capacidad.
• Los resultados – El resultado más importante de la reunión de planificación del sprint es que el equipo puede describir el objetivo del sprint y cómo comenzará a trabajar hacia ese objetivo. Esto se hace visible en el sprint backlog.

Ejecutar un gran evento de planificación del sprint requiere un poco de disciplina. El product owner debe estar preparado, combinando las lecciones de la revisión del sprint anterior, los comentarios de los interesados y la visión del producto, de modo que establezcan el escenario para el sprint. En aras de la transparencia, el product backlog debe actualizarse y perfeccionarse para brindar claridad. El refinamiento del backlog es un evento opcional en scrum porque algunos backlogs no lo necesitan. Sin embargo, para la mayoría de los equipos, es mejor reunir al equipo para revisar y refinar el trabajo pendiente antes de la planificación del sprint.

Si tienes un sprint de dos semanas, ejecuta una reunión de refinamiento del backlog en medio del sprint. Es genial para el equipo dar un paso atrás del sprint y mirar lo que sigue. No solo ayuda a prepararse para la planificación del sprint, sino que también puede brindar una perspectiva diferente para el trabajo actual.

La planificación del sprint debe limitarse a no más de dos horas por cada semana del sprint. Entonces, por ejemplo, la reunión de planificación del sprint para un sprint de dos semanas no duraría más de dos horas. Esto se llama “timeboxing”, o establecer una cantidad máxima de tiempo para que el equipo realice una tarea, en este caso, planificar el sprint. El scrum master es responsable de asegurarse de que la reunión se lleve a cabo en el horario establecido. Si el equipo está contenido antes de que finalice el plazo, entonces el evento ha terminado. Un timebox es el tiempo máximo permitido; no se permite un tiempo mínimo.

Enfoca la primera parte de la planificación del sprint en el objetivo del sprint en lugar de en los detalles del trabajo pendiente. Al centrarse en el objetivo en lugar del trabajo, es posible encontrar alternativas inteligentes sobre cómo se logra ese objetivo.

Durante la planificación del sprint, es fácil “atascarse” en el trabajo, centrándose en qué tarea debe ser la primera, quién debe realizarse y cuánto tiempo tomará. Para trabajos complejos, el nivel de información que conoces al principio puede ser bajo, y gran parte de ella se basa en suposiciones. Scrum es un proceso empírico, lo que significa que no puedes planificar por adelantado, sino aprender haciendo y luego retroalimentar esa información en el proceso.

El objetivo del sprint describe la meta del sprint en un alto nivel, pero los elementos del backlog también se pueden escribir con un resultado en mente. Las historias de usuario son una excelente manera de describir el trabajo desde el punto de vista del cliente. Las historias de usuario, escritas como la que se muestra a continuación, enfocan los defectos, los problemas y las mejoras en el resultado que buscan el cliente en lugar del problema observado.

Como <tipo de usuario>, deseo <un objetivo> para que <una razón>.

Al agregar resultados claros y medibles a la historia de usuario, los resultados se pueden medir claramente y sabes cuándo ha terminado. Al obtener la mayor claridad posible sobre el trabajo en el que se enfoca el equipo, todos obtienen la transparencia necesaria para comenzar con el trabajo. Por ejemplo, dejar las cosas vagas es mucho peor que describir algo como una pregunta a responder durante el sprint.

No saber algo es diferente a ser vago. No ignores las incógnitas, son la realidad de hacer un trabajo difícil. Pero no las ocultas usando palabras vagas. En su lugar, se claro cuando no sepas algo y encuadra el trabajo en términos de comprensión.

La planificación del sprint requiere cierto nivel de estimación. El equipo necesita definir qué se puede o no se puede hacer en el sprint: esfuerzo estimado vs capacidad. La estimación a menudo se cofunde con los compromisos. Las estimaciones son, por su propia naturaleza, pronósticos basados en el conocimiento disponible. Técnicas como los puntos de historia o el tamaño de las camisetas agregan valor al proceso al brindarle al equipo una forma diferente de ver el problema. Sin embargo, no son herramientas mágicas que puedan descubrir la verdad cuando no hay ninguna. Cuantas más incógnitas, menos probable es que la estimación sea correcta.

Una buena estimación requiere un entorno basado en la confianza en el que la información se proporcione libremente y los supuestos se discutan en la búsqueda del aprendizaje y la mejora. Si las estimaciones se utilizan de manera negativa y de confrontación después de que se completa el trabajo, entonces es probable que las estimaciones futuras sean mucho más grandes para garantizar que nunca vuelvan a equivocarse o que el tiempo necesario para crearlas sea mucho más largo a medida que el equipo lo adivina preocupándose por las implicaciones de equivocarse.

Explora el uso de diferentes técnicas de estimación, como el tamaño de la camiseta o los puntos de historia. Diferentes técnicas pueden proporcionar diferentes visiones del problema.

Es fácil empantanarse tanto en los detalles de la planificación del sprint que se olvida que el objetivo de la planificación del sprint es construir un plan “suficiente” para el siguiente sprint. Ese plan no debería convertirse en un mono para la espalda del equipo, sino que debería centrar al equipo en resultados valiosos y permitir barreras para la autoorganización. Un buen plan de sprint motiva a todos al definir un resultado y un plan claro para el éxito. Pero ten cuidado al planificar demasiado por adelantado. En lugar de construir el plan de sprint más completo, “cada minuto del sprint se contabiliza”, concéntrate en el objetivo y construye lo suficiente de un sprint backlog para comenzar. A continuación, asegúrate de que el product backlog está ordenado para permitir que el equipo retome el trabajo si cumplió el objetivo del sprint tempranamente.

Scrum es un marco de procesos destinado a resolver problemas complejos. Los problemas complejos requieren un proceso empírico (aprender haciendo). 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 cambio, concéntrate en los resultados y continua. No tiene por qué ser difícil, incluso si el problema que estás resolviendo lo es.