scrum

¿Cuántas Sprint Planning se pueden hacer en un Sprint?

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!

wedding-rings-3611277_1280

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

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. 

 

glasses-4704055_1280

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?

 

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s