El seguimiento del sprint se realiza a través de una reunión diaria denominada “Scrum diario” y debe tener las siguientes características:

  • Su duración se establece entre 5 y 15 minutos como máximo.
  • Debe realizarse en el mismo lugar y a la misma hora todos los días, para reducir la complejidad.
  • La reunión puede ser abierta, y si así lo decide el Scrum master, se permite asistir cualquiera de la empresa. Pero en la reunión sólo puede participar el equipo.
  • No se debe discutir, ni se deben producir interrupciones entre los miembros del equipo. Debe hablar un miembro cada vez.
  • La reunión debe realizarse de pie, lo que evita que se alargue.
  • Los temas que se deben tratar en la reunión diaria son:
  • ¿Qué hemos hecho desde ayer?
  • ¿Qué vamos a hacer hoy?
  • ¿Qué impedimentos han surgido?
  • La figura del Scrum master es muy importante, sólo él hace las preguntas.
  • Revisión del sprint

Al finalizar el sprint se convoca una reunión de revisión que permita adaptar la lista de producto si se considera necesario. El objetivo de esta reunión es el aprendizaje. Fomentar la colaboración y la retro-alimentación.

A la reunión deben asistir el equipo Scrum y los invitados importantes que decida invitar el dueño del producto. En la misma, el dueño del producto debe explicar qué elementos de la lista de producto se ha terminado y cuáles no.

La reunión no debe tener una duración superior a las cuatro horas, si el sprint que se está revisando es de un mes de duración. En caso de sprints más cortos, la reunión debe durar menos tiempo.

En la reunión de revisión, debe quedar claro que el sprint ha sido terminado, el equipo debe demostrarlo y debe exponer los problemas con los que se ha encontrado.

Esta reunión es muy importante para el futuro del proyecto porque permitirá que se adapte la lista del producto a nuevos retos y oportunidades que puedan surgir.

  • Retrospectiva del sprint

Cuando el sprint ha finalizado es necesario realizar una reunión de retrospectiva, hacer una revisión de las cosas que se han hecho bien y de las que se han hecho mal, antes de comenzar con el siguiente sprint. Es una reunión necesaria para el aprendizaje, que nos vendrá del análisis de las cosas que hemos hecho mal.

Como en todas las reuniones, es preciso priorizar, prestando mayor tiempo y atención a las cosas más importantes, sean buenas o malas. No deberá durar más de tres horas en un sprint de un mes, tiempo que variará.

El propósito de la reunión de retrospectiva es revisar los elementos que salieron bien, es contestar a las siguientes preguntas:

  1. ¿Qué hemos hecho bien?
  2. ¿Qué hemos hecho mal?
  3. ¿Qué podemos mejorar la próxima vez?
  • Medición

La gestión en la empresa siempre se realiza apoyándose en información que se va recopilando de diversas fuentes y sintetizando en herramientas de fácil lectura y acceso como son, por ejemplo, los Cuadros de Mando. Esa información la vamos recopilando a través de la medición.

  • Consideraciones

La información dentro de la empresa es costosa de recopilar, por esa razón es importante sintetizar lo que se precisa para una correcta gestión, estimando adecuadamente la relación coste-beneficio.

También es necesario entender que “medir no es un fin en sí mismo”. No debemos crear complejos procesos de medición que supongan una carga de tiempo innecesaria para el proyecto que estamos desarrollando.

El hecho de medir implica un aumento de la burocracia, pero para la filosofía Scrum lo que se busca es la simplicidad con la máxima aportación de valor posible. Esos son los principios que debemos aplicar a la hora de seleccionar los indicadores más adecuados.

A la hora de seleccionar nuestros indicadores de gestión, en este caso indicadores de gestión de proyectos, debemos partir de la premisa: “Cuantos menos, mejor”. Para la utilización de un indicador, una vez que lo hemos seleccionado, atenderemos a las siguientes consideraciones:

  • ¿Para qué vamos a usar el indicador?
  • ¿Qué valor nos aporta el hecho de incorporar ese indicador a nuestra gestión?
  • Unidades

Las unidades que se manejan en la medición de la gestión de proyectos ágil son básicamente tres:

  • Trabajo
  • Tiempo
  • Velocidad
  1. Trabajo

En el desarrollo de un proyecto encontramos dos tipos de trabajo que necesitaremos mediar. Por un lado, el trabajo ya realizado y por el otro, el trabajo pendiente de realizar.

El trabajo realizado es fácil de medir y para ello se pueden utilizar infinidad de unidades que nos permitirán saber cuánto trabajo hemos realizado (unidades producidas, partes desarrolladas del proyecto, metros construidos o pintados, etc…). Pero la metodología ágil no se preocupa del trabajo realizado, se centra en medir el trabajo pendiente de realizar, que lo considera más importante. Por esta razón, el grado de avance de un proyecto ágil se medirá a través del trabajo pendiente de realizar.

Con la medida del trabajo pendiente de realizar, la metodología ágil, evalúa el esfuerzo y la duración prevista para la realización del trabajo. La estimación precisa y objetiva de trabajo necesario es un valor muy cuestionable, porque no se puede conocer con exactitud el esfuerzo que se requiere, ya que en la mayoría de las situaciones no existe una única manera de hacer las cosas y el entorno en el que se mueve el proyecto es complejo e intervienen multitud de variables. Y si no somos capaces de evaluar el trabajo de manera exacta, tampoco podremos calcular el tiempo que nos llevará realizarlo. Por esta razón, la metodología ágil no pretende realizar este tipo de medición porque se supone excesivamente costoso. La metodología ágil se apoya en las siguientes premisas para la medición: No busquemos métricas precisas y utilizamos el “juicio de expertos” para la estimación.

1.- Tiempo

En este apartado es importante fijarse en la diferencia que se hace en la gestión ágil al hablar del tiempo. Por un lado, tenemos el “tiempo real” y por el otro, el “tiempo ideal”. Como mejor se entienden estos dos conceptos es a través de la utilización del concepto de tiempo en algunos deportes. Por ejemplo, si preguntamos cuánto dura un partido de baloncesto, la contestación sería 40 minutos. Ese tiempo es el “tiempo ideal”, el tiempo efectivo de juego, pero el “tiempo real” será probablemente de dos horas.

Una jornada laboral puede durar realmente 8 horas, pero cuánto tiempo de esa jornada está verdaderamente dedicado a la tarea que deseamos evaluar. Por lo tanto, para hablar de tiempo, tenemos que hablar de tiempo ideal. En este caso, el “tiempo ideal” deja de ser una unidad de tiempo para convertirse en una unidad de trabajo (esfuerzo).

2.- Velocidad

La gestión ágil define la velocidad como la cantidad de trabajo realizado por unidad de tiempo. La velocidad se suele medir en puntos (véase página 18, “Estimación inicial”). Dado que los sprints no son iguales, ni en ellos intervienen las mismas personas del equipo, se suele hablar de puntos promedio por persona a la hora de medir.

No obstante, cada empresa institucionaliza sus unidades y su forma de medir. Lo más importante es que la métrica que se emplee, su definición y utilización sea igual en toda la organización.

  • Herramientas

La gestión ágil utiliza varias herramientas de medición:

Gráfico de producto

grafico-product-backlog

También denominado gráfico “burn up”, es una herramienta del propietario del producto que proyecta el tiempo de realización del proyecto en base a la velocidad del equipo.

En el eje de ordenadas se representa la duración del sprint en días, por lo que se representan fechas, generalmente la fecha de inicio y finalización de cada sprint.

En el eje de abscisas se representa el esfuerzo estimado en cada sprint en puntos de historia.

En la herramienta que acompaña este curso podrás encontrar el gráfico de “burn up” en el cuadro de mando.

Gráfico de avance (sprint burn-down)

sprint-burndown_1

Se trata del gráfico que se actualiza en cada reunión del seguimiento del sprint (véase punto 4.3.3).

Como en el gráfico anterior se representan los puntos de historia del sprint frente a los días de realización. Como hemos visto anteriormente, la gestión ágil no pretende controlar el trabajo que se lleva realizado, si no el trabajo que queda pendiente y si el tiempo para realizarlo es suficiente para ese cometido.

En la reunión diaria nos iremos fijando en la evolución del gráfico, que normalmente se apartará de la velocidad ideal (línea verde) de la real (línea amarilla).

Si existe una desviación muy grande en la parte superior de la línea ideal, significa que estamos desarrollando más trabajo que el que teníamos planificado, por lo que deducimos que en ese tiempo deberíamos haber planificado. Se dice que se trata de un sprint “subestimado”. Podemos corregir esta tendencia eliminando historias del sprint para ajustarlo a la velocidad programada.

Si la desviación se produce en la parte inferior de la línea ideal, significa que hemos “sobrestimado” el sprint y que el sprint podría estar realizando más tareas para ajustarse a la velocidad estimada.

Es en la reunión diaria cuando se realizarán los cambios necesarios para ajustar la velocidad a la ideal estimada.

  • El tablero scrum

El “tablero Scrum” se basa en la filosofía kanban, pero no debemos confundirlo con esta metodología. El tablero se utiliza en las reuniones de seguimiento del sprint para analizar el trabajo pendiente y la evolución del mismo. La parte visual es similar, pero ambas herramientas y metodologías poseen diferencias entre sí.

El Kanban es un sistema de información que controla de modo armónico la fabricación de los productos necesarios en la cantidad y tiempo necesarios en cada uno de los procesos que tienen lugar tanto en el interior de la fábrica, como entre distintas empresas.

Kanban significa “letrero” o “cartelera” y se trata de un concepto relacionado con la producción lean y just-in-time (JIT). De acuerdo con Taiichi Ohno, el hombre acreditado con el desarrollo Just-in-time (JIT), kanban es un medio a través del cual se logra JIT. Kanban no es un sistema de control de inventario. Más bien, es un sistema de programación que te dice qué producir, cuándo producirlo y cuánto producir. La necesidad de mantener una alta tasa de mejoras llevó a Toyota a idear el sistema kanban, que se convirtió en una herramienta eficaz para apoyar el funcionamiento del sistema de producción en su conjunto. Además, resultó ser una excelente forma de promover mejoras porque la reducción del número de kanban en circulación puso de relieve las áreas problemáticas.

También se denomina “sistema de tarjetas”, pues en su implementación más sencilla utiliza tarjetas que se pegan en los contenedores de materiales y que se despegan cuando estos contenedores son utilizados, para asegurar la reposición de dichos materiales. Las tarjetas actúan de testigo del proceso de producción. Otras implementaciones más sofisticadas utilizan la misma filosofía, sustituyendo las tarjetas por otros métodos de visualización del flujo. (fuente Wikipedia)

tablero-kanban

De la misma forma que scrum, el sistema divide el trabajo en bloques que se escriben en una tarjeta y se coloca en el muro. Utiliza columnas con nombre para ilustrar dónde está cada elemento en el flujo de trabajo. Asigna límites concretos a cuántos elementos pueden estar en progreso en cada estado del flujo de trabajo y optimiza el proceso para que el tiempo de ciclo sea tan pequeño y predecible como sea posible.

Ambos sistemas son muy adaptables, pero se diferencian en, sobre todo, en que Scrum prescribe iteraciones de duración fija, kanban no.

Scrum prescribe roles (dueño de producto, Scrum master y equipo) pero kanban no prescribe ningún rol.  No significa que no se prescriban los roles, simplemente que no tienes por qué hacerlo. En ambos se pueden añadir nuevos roles, pero no es aconsejable. Es muy importante asegurarse de que realmente este nuevo rol aporta valor y que tampoco entra en conflicto con los roles actuales. La mentalidad es “menos es más”, por lo que, en caso de no estar seguro, es mejor no añadir el nuevo rol al proyecto.

tablero-scrum

Ambos tableros muestran una serie de diferencias:

  • En cada columna del tablero Kanban se indica el número de elementos que puede haber en ellas. En Scrum no está limitado este número, no hay ninguna regla que impida que el equipo ponga todos los elementos en marcha al mismo tiempo. No obstante, en la experiencia se aprende que es mejor no empezar demasiados elementos e incluso limitar el número, lo que acerca ambas metodologías.
  • Ambos son empíricos. Se experimenta con el proceso y se adapta al entorno. Ninguno de los dos proporciona todas las respuestas, simplemente algunas reglas a la hora de aplicarlos.

tablero-scrum-evolucion tarjetas-backlog

  • Durante la iteración, Scrum no permite los cambios, aunque sí que se pueden añadir nuevas historias en la pila de producto. Kanban, por el contrario, permite realizar cambios siempre que no se sobrepase el número de elementos. Si queremos añadir un nuevo elemento y ya tenemos el número máximo, sólo podremos hacerlo si sustituimos uno de los actuales por uno de los nuevos.
  • En cada Sprint, se limpia el tablero Scrum para iniciar uno nuevo. Cada vez que se finaliza un sprint, el tablero se vacía y en la reunión de planificación del siguiente, se vuelve a completar el tablero. En Kanban, el tablero se mantiene durante todo el proceso.
  • El tablero Scrum es propiedad del equipo, que es multifuncional y contiene todos los elementos y conocimientos para completar el sprint. En Kanban, los equipos no tienen que ser multidisciplinares y el tablero no tiene que pertenecer a un solo equipo.
  • Un equipo Scrum sólo se comprometerá con los elementos que creen que pueden terminar en una iteración (basado en la definición de “Hecho”). Los equipos de Kanban tratan de minimizar el tiempo de entrega y el nivel de flujo, por lo que, indirectamente, se crea un incentivo para descomponer los elementos en pedazos relativamente pequeños. Pero no hay ninguna norma explícita que indique que los elementos deben ser lo suficientemente pequeños como para caber en un intervalo de tiempo específico.
  • En Scrum, los equipos tienen que estimar el tamaño relativo (= cantidad de trabajo) de cada elemento al que se comprometen. Sumando el tamaño de cada elemento completado al final de cada sprint, obtenemos la velocidad. En Kanban, no se prescribe la estimación. Así que si necesitas comprometerte necesitas decidir la forma de garantizar la previsibilidad.
  • Ambos están alineados con los valores y principios lean y ágiles.