Planificar en Agile: más allá de la estimación.

Vivimos en un mundo en constante planificación. En Agile no rehuimos de los planes, pero creemos que por encima del plan está la flexibilidad para realizar cambios. La adaptación al cambio nos hace ser competitivos y esto es vital en mercados cambiantes. Pero, ¿en qué consiste planificar?

El acto de planificar lo llevamos en el ADN en el mundo del software. El motivo principal es que hemos heredado de industrias como la del automovilismo o la arquitectura el hecho de no empezar nada sin que haya un plan que trace nuestro “destino”.

Planificar consiste en analizar todas las tareas que hay que llevar a cabo, estimarlas (generalmente en tiempo) y colocarlas en una línea temporal distribuyéndolas entre las personas que las van a realizar.

Las planificaciones han evolucionado mucho y podemos llevarlas a cabo de formas muy diferentes. Hay Jefes de Proyectos que realizan en solitario las planificaciones (lo cual es una mala práctica desde el punto de vista de Project Manager Institute), equipos de expertos que estiman todas las tareas, incluso en otras ocasiones son los propios equipos los que hacen esas estimaciones.

El problema principal de las planificaciones es que se trata de organizar el futuro muy a largo plazo y esto ocasiona mucha frustración cuando el plan no se cumple. Además, las reuniones de planificación suelen ser muy pesadas, largas y poco productivas.

¡Vamos a ver cómo solucionarlo con Scrum!

¿Cómo son las planificaciones en Scrum?

En Scrum la planificación se realiza al inicio de cada iteración (Sprint). De los cinco eventos que componen Scrum, es el más largo y uno de los que se hace más pesado.

En este evento el objetivo principal es responder a dos preguntas:

• ¿Qué incremento podemos entregar en este Sprint?
• ¿Cómo podemos entregar ese incremento?

Por tanto, lo primero que tendremos que tratar es el “qué”. En esta parte, el Equipo Scrum se reúne para organizar el trabajo que se va a realizar. El resultado de esta parte es obtener un objetivo realista y realizable durante el Sprint y una previsión del alcance que el Development Team será capaz de acometer.

En esta parte es muy importante que se cree un diálogo entre el Product Owner y el Development Team sobre los detalles de todas las tareas.

Para que esta primera parte sea exitosa, hay varias ideas que podemos aplicar. Lo que más tiempo nos ahorrará es tener todos los ítems refinados. Refinados significa con el detalle suficiente como para que el Development Team pueda entender, estimar y dividir cada ítem en tareas técnicas. Recordemos que no debe incluir detalle técnico, de eso se encargará nuestro Development Team; el Product Owner sólo debe poner el foco en “qué” se quiere o se necesita.

Más tareas que podemos hacer son aprovechar el tiempo entre la anterior Retrospective y el Sprint Planning para que el Development Team se lea los ítems y plantee dudas previamente que se puedan tratar durante el evento.

Una vez respondida la primera pregunta sobre qué vamos a entregar, tendremos que responder la pregunta: ¿cómo lo vamos a hacer?

En esta parte del Planning solemos encontrar un error muy típico en los equipos: centrarse en la estimación. Muchos equipos pasan horas estimando hasta el último detalle sin pensar cómo se van a organizar para alcanzar el objetivo del Sprint.

¿Qué dice la Scrum Guide sobre esta parte del evento?

La Guía Scrum habla de que el Development Team descompondrá los ítems en tareas técnicas que se abordarán durante el Sprint, con el objetivo de proyectar la cantidad de ítems que se van a completar, es decir, ser capaces de saber cuánto entregaremos.

Sin embargo, vemos que muchos equipos acaban por estar delante de una pantalla mirando tarea por tarea y haciendo estimaciones, pero sin pararse a pensar en la organización del trabajo.

¿Qué podemos hacer para que esta parte sea exitosa?

Una idea que nos está funcionando con muchos equipos de Paradigma es ponernos a construir entre todos el plan en un panel físico.

Para fomentar que eso ocurra, proponemos levantar al Development Team de sus asientos para ponerlos a fabricar su propio plan. Además, así los alejamos de distracciones (móvil u ordenador) y mejoramos nuestro foco. Tenemos un equipo que incluso ha puesto la norma de que la Sprint Planning sea una “Standup” Sprint Planning y siempre se haga de pie.

Si el equipo dispone de tablero físico ya podemos empezar, si no disponemos de uno podemos utilizar un “brown paper” y pegarlo en una pared que tengamos cerca. Recopilamos post-its de distintos colores y tamaños, y cinta aislante para generar separadores.

¿Qué forma debería tener un buen panel físico?

Es muy típico comenzar con un tablero con el formato clásico “to do / doing / done”. El problema de este formato es que requiere mucha madurez, porque asume que “cualquiera” hace cualquier tarea. Para equipos que están aprendiendo a organizarse proponemos usar modelos diferentes.

Un ejemplo es dividir el panel en columnas; una por cada semana y colocar en cada columna los ítems que creemos que vamos a hacer durante esa semana. De esta manera reducimos la incertidumbre temporal a una semana y hacemos una estimación menos detallada, pero posiblemente más efectiva.

Una vez colocados los ítems en post-its (unos encima de otros, según prioridad), a su lado colocamos post-its más pequeños con las tareas técnicas que dicho ítem va a necesitar. Una vez hecho esto, podemos hacer una estimación del ítem en puntos de historia.

¿Cuánto trabajo va a llevar este ítem si tenemos tareas de tipo front-back-servicios rest y mongo? Si nos regimos por la tabla Fibonacci, posiblemente obtendría un 8 o un 13 porque es complejo. No se trata de no estimar, se trata de no centrar el foco de la reunión en la estimación.

Otro ejemplo de organización que hemos utilizado es hacer una tabla de días del Sprint y personas que van a participar. Marcamos los días de vacaciones y repartimos los ítems entre los miembros. Es cierto que esta técnica de preasignar tareas es menos Scrum, pero ayuda muchísimo en estas tres situaciones:

• Equipos poco maduros que aún no saben la cantidad de trabajo que son capaces de hacer.
• Equipos muy grandes donde la coordinación es más difícil y se necesita de más madurez.
• Equipos con hitos importantes dentro del Sprint que requieren que una serie de ítems estén completados y que no se quede nada sin hacer porque tumbaría el trabajo de todos.

Por ejemplo, teníamos un equipo que durante un Sprint tenía que organizar una rotación para realizar una tarea un poco pesada. El modelo de personas&días nos ayuda a organizar qué día lo va a hacer cada persona.

¿Cómo podemos hacer seguimiento de los ítems con este tipo de herramientas?

En el modelo por semanas es importante ir marcando las tareas finalizadas. Los equipos que apuestan por este tipo de tablero suelen pintar un check en las tareas finalizadas.

Si lo que necesitamos es poner el foco en tareas que debemos acabar, podemos marcar con una flecha el ítem más prioritario que aún no está completado, así evitaremos que el equipo haga cosas menos prioritarias en vez de cerrar ítems. Cada vez que las tareas de un ítem finalizan, la flecha desciende al siguiente ítem.

Para el modelo por días es importante que, cuando llegue la Daily Scrum, tengamos los días anteriores “limpios”. Cada persona tiene que mover sus post-its, o bien porque se ha terminado o porque se le ha alargado, para lo que tendrá que replanificar sus tareas de los días siguientes (por ejemplo, dándoselo a otro compañero que haya acabado antes).

De esta manera forzamos a que el equipo re-planifique cada día en la Daily y así los post-its acaban moviéndose para reflejar el estado actual de nuestro Sprint en todo momento.

Esto nos ayuda a evitar la típica situación en la que el día de la Sprint Review le decimos al Product Owner “no llegamos”. El Product Owner puede estar mejor conectado con el Development Team si en cada momento vamos adaptando nuestro Sprint Backlog gracias a la transparencia que le mostramos.

¿Qué hemos aprendido?

Planificar en Scrum es posible. El hecho de que sea una planificación diferente, lejos de las prácticas tradicionales no significa que no funcione, todo lo contrario. En Scrum encontramos diferentes formas de planificarnos, lo que hace que podamos adaptarlas a nuestras necesidades.

¡Pon a la gente a trabajar! Preparar una planificación nunca debe ser una ejercicio de estar sentados mirando una pantalla. Estar levantados nos ayuda a activarnos a pensar. ¿Qué hay detrás de esta tarea? ¿Cómo encaja esta tarea con el resto? Todo esto lo podemos conseguir utilizando herramientas visuales.