Dentro del marco de trabajo de Scrum, una reunión de planificación de sprint produce los siguientes artefactos:
- El objetivo del sprint, que es una breve descripción de lo que el Product Owner y el equipo quiere lograr en el Sprint.
- El Sprint Backlog, que es un conjunto de historias de usuario ya estimadas y priorizadas, así como las respectivas tareas que cada integrante del equipo realizara para cumplir el objetivo del sprint.
El equipo debe tener claridad de los artefactos antes mencionados a fin de poder cumplir con el objetivo mencionado para el Sprint. Así mismo, para obtener el mejor valor para el cliente, se deben contar con las historias de usuario, el equipo debe tener claro cada una de ellas, así como también contar con los prototipos para las historias de usuario a ser trabajadas en el Sprint. Mientras que la historia de usuario describe la funcionalidad, los prototipos describen el formulario.
Pasos de la reunión de planificación del Sprint.
1.- Revisar el BackLog: El Product Owner inicia realizando una descripción de las historia de usuario desde el primer requerimiento, con su respectivo prototipo. El equipo usualmente realiza consultas relacionados a la historia de usuario, las cuales son absueltas por el Product Owner. Cuando el equipo tiene claro el detalle de las historia de usuario, el equipo elabora un listado de tareas para cada historia de usuario. El equipo de pruebas, también agrega las tareas relacionadas a las pruebas de aceptación. Sin embargo, el equipo de pruebas puede agregar pruebas adicionales durante el desarrollo del sprint.
2.- Estimar los tiempos del sprint backlog: Una vez revisado cada historia de usuario del Backlog, el equipo inicia la estimación de los tiempos desde el primer requerimiento del backlog. Una de las técnicas preferidas es utilizas los puntos por historia y utilizar Planning Poker de forma que todos están sincronizados y la planificación es aceptada por el equipo.
3.- Ejecutar: basado en el Velocity del equipo y el tiempo definido para el sprint, el equipo determina que historias de usuario deben estar concluidas para el final del Sprint, basados en la definición de HECHO y sin escapar a las pruebas de usuario.
Una vez revisado estos puntos, consideremos algunos otros que contribuyen a una planificación fructífera del sprint.
- Fijar días de inicio y fin: El sprint debe iniciar y terminar el mismo día, por lo tanto el sprint debería ser de una semana, dos semanas o un número de semanas determinado. Luego, si define el sprint de una semana y que inicia lunes y termina viernes, esto no debe cambiar durante el proyecto. Esto ayuda al equipo a entrar en un ritmo periódico. Además del desarrollo del proyecto, este tiempo debe incluir la planificación del sprint y la retrospectiva al final del proyecto.
- Incluir a todos: La planificación del sprint debe incluir a todos los integrantes del proyecto (El Product Owner, y de ser posible el cliente), el equipo (incluyendo los desarrolladores, el equipo de calidad, diseñadores) y el Scrum Master.
- Sincroniza el plan con el cliente: Si el cliente no se encuentra en la planificación, y esta es dirigida por el Product Owner, es importante que este informe del plan al cliente. El cliente debe tener claro estos tiempos, de forma que está seguro lo que recibirá al final de cada sprint.
- Incluye picos: Como sucede en muchos proyectos, debe existir funcionalidad que nadie conoce. Tal vez esta funcionalidad que requiera realizar una prueba de concepto. Para estos puntos, es bueno incluir tiempos adicionales en la planificación uno o dos días de investigación, tal vez, a fin de revisar la viabilidad de dicha funcionalidad. Esto se hace incluso antes de iniciar el sprint, de forma que se reduce la incertidumbre y ayuda a una mejor planificación del sprint.
Algunas otras consideraciones adicionales son:
- Estar seguro de que las historias de usuarios épicas están divididas en forma adecuada, así como tener los prototipos para cada una de ellas.
- El sprint tiene un tiempo determinado y este no se debe extender, aun si tenemos historias de usuario sin terminar. No extender el tiempo del sprint.
- No incluir tiempo extra. Inicialmente puede parecer una buena idea incluir determinado tiempo extra, pero esto a la larga afecta la productividad del equipo.
- No agregar más trabajo, una vez establecido el sprint.
Tener en cuenta estas consideraciones ayuda a tener una mejor planificación del sprint y que el proyecto pueda terminar dentro de los tiempos y plazos establecidos.
Artículo basado en Better Sprint Planning.
