En Scrum, disponemos de cuatro eventos (Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective) todos ellos envueltos por un meta-evento llamado Sprint.
La Sprint Planning marca el inicio del Sprint, es el momento en el que inspeccionamos el Product Backlog (lo que podría contener nuestro producto) y nos adaptamos creando un Sprint Backlog (plan para organizar el trabajo en el Sprint).
Para muchos equipos la Sprint Planning es clave, cada evento es una oportunidad de inspección y adaptación que nos permite hacer una buena gestión y desarrollo de producto. Dado que el equipo que va a desarrollar el producto necesita organizarse, la Sprint Planning es un buen momento para hablar sobre cómo nos vamos a organizar.
Estar comprometidos o tener un compromiso
Uno de los valores de Scrum es el compromiso. Muchas personas confunden el estar comprometido con tener un compromiso. En un modelo tradicional, nos forzaban a dar fechas cuando teníamos un conocimiento reducido de lo que teníamos que hacer. Dar fechas no es estar comprometido, tener coraje para decir “no sé cuándo va a estar” es estar comprometido. Nos comprometemos con nuestro equipo, con nuestro cliente, con tratar de hacer las cosas bien… ¡pero no ser suicidas dando fechas!
En la Sprint Planning no existe la palabra compromiso
Para muchos equipos, el resultado de la Sprint Planning es un compromiso en forma de puntos de historia (puntos comprometidos) o en historia de usuario (historias comprometidas). La palabra compromiso se quitó hace muchos años de la Sprint Planning, y fue sustituida por la palabra previsión. El equipo no se compromete con un alcance, hacen una previsión de lo que creen que serán capaces de hacer. Esto permite introducir cambios durante el Sprint, y evita una tensión innecesaria con un compromiso que el equipo adquiere cuando hay incertidumbre.
Cuándo tenemos mucha incertidumbre
A veces, un equipo no es capaz de determinar lo que va a ser capaz de hacer un Sprint. Esto ocurre cuando llevamos poco tiempo trabajando juntos o cuando nos planteamos funcionalidades que desconocemos por algún tema técnico o funcional.
Una vez, acompañé a un equipo que tenía que tomar una decisión técnica para saber qué tipo de tecnología iba a utilizar. En la Sprint Planning todavía no teníamos la decisión tomada, lo que impactaba en el desarrollo del Sprint. El equipo tomó la siguiente decisión: un miembro del equipo iba a investigar la tecnología y, mientras, el resto avanzaba en tareas secundarias. Una vez tomada la decisión, se volvieron a reunir para planificar el resto del Sprint.
Hay un concepto que genera dudas, y es que no tenemos que llenar el Sprint en la Sprint Planning. Cuando tenemos más complejidad de la que somos capaces de abordar, es mejor planificar unos cuantos días y reunirnos periódicamente durante el Sprint, para organizarnos con el resto de items que queramos añadir.
Poniendo foco en la Sprint Planning
Hace unos meses, acompañé a un equipo nuevo en Scrum. Su negocio cambiaba constantemente y les costaba muchísimo dedicar varios Sprints a un mismo objetivo de negocio. En una Retrospectiva, el Product Owner reflexionaba sobre los numerosos frentes abiertos a la vez que tenían , y sobre cómo esto les impedía entregar software con valor.
Tras la Retrospectiva, arrancamos la Sprint Planning. El Product Owner explicaba lo que le gustaría que abordáramos, y dibujamos siete cosas diferentes que eran importantes e imprescindibles. Tras el aprendizaje de la Retrospectiva, les propuse que eligiéramos solo una y que, cuando acabaran, podríamos empezar con la siguiente. Después de negociar, llegamos a un acuerdo de solo abordar dos PBis. La previsión del equipo era que en un par de días estarían hechos y, después, volveríamos a reunirnos para planificar los siguientes items. Tardaron ocho días en completarlo, por lo que se dieron cuenta de que poniendo foco eran capaces de acabar más aspectos importantes que si hubieran arrancado con las siete a la vez. Al final, fueron capaces de entregar cuatro de los items.
Este es uno de los motivos por el que, a veces, es mejor planificar varias veces que dedicar mucho tiempo al principio para luego no conseguir entregar.
La importancia del Sprint
A medida que ganamos experiencia con Scrum, nos damos cuenta de que el Sprint es una herramienta muy importante. Al principio, parece que un Sprint es solo un periodo de tiempo en el que ocurren cosas. Sin embargo, el Sprint es una garantía, nos asegura que al menos una vez inspeccionamos y adaptamos nuestro backlog; inspeccionamos y adaptamos el resultado del trabajo; e inspeccionamos y adaptamos cómo estamos trabajando.
Por eso, no está prohibido hacer varias Sprint Planning, Reviews o Retrospectivas, siempre que el equipo determine que lo necesita. Eso sí, como mínimo tendremos que ejecutar una vez cada evento y en periodos inferiores a treinta días.
Y tú… ¿Planificas siempre todo antes de empezar el Sprint?
Hola, me gusta mucho esa perspectiva ir en constante alineamiento sobre los objetivos. Pero tengo una duda, cuando un Scrum master hace hincapié en los gráficos de quemado (burn down chart) no estaríamos “sesgando al equipo” a tener que hacer todo al incio porque sino su grafico de quemado se vería muy en subidas y bajadas, eso también es correcto?
Puede ocurrir pero el burndown es una herramienta opcional, de hecho no soy muy fan de ella