20180930 UCI Road World Championships Innsbruck Men Elite Road Race Valverde wins 850 2058

Hace poco escuché a un colega comentarme la importancia de elaborar sprints de duración fija, por ser parte del marco metodológico de la empresa, y me dio que pensar sobre las ventajas y desventajas de esta afirmación. Por aquí os dejo mis reflexiones:

Comparto y entiendo la necesidad de adherirse a un marco metodológico de Scrum de manera más o menos estricta, con el objetivo de que todas las partes puedan ver un avance significativo del cambio a dicha metodología, y para evitar (en definitiva) que posibles “vicios” o “gaps” a nivel de adopción o conocimiento, puedan interferir en la opinión de la gente.

Mucha gente no ve un beneficio claro sobre los proyectos cuando se utiliza Scrum respecto a otras metodologías por desconocimiento, o porque no lo está aplicando bien, y casi nunca es porque la metodología no funciona. Evidentemente, si no haces ninguna liturgia, tu equipo no tiene conocimiento en Scrum, y el que escribe las historias de usuario es el scrum master y no el owner, pues el problema es que no se está aplicando bien, y la metodología en si misma no tiene que ver con el problema.

Otra cosa muy diferente es optar por pequeñas variaciones dentro de la metodología para adaptarla a la naturaleza de tu empresa, y este, a mi entender, (la duración de los sprints) puede ser uno de los puntos “susceptibles” de que seamos más o menos flexibles.

Y no hablo de la duración una vez iniciado el sprint, que, salvo catástrofe, debería ser acorde a lo estimado. Me estoy refiriendo al total de tiempo necesario entre iteración.

  • En muchos casos el equipo de desarrollo acuerda el listado de historias de usuario que se van a desarrollar en una iteración con el owner, ordenados por prioridad, y la duración de la iteración viene  definida por la estimación en puntos de esfuerzo, que tiene su equivalencia en un tiempo determinado (8 días, 12 días, 20 días…). Este tiempo determinado siempre se suma a una serie de liturgias  que ocurren al principio y final de ese tiempo estimado, donde,  si y solo si, se da por cerrada una funcionalidad, se puede asociar (o no) a una entrega en un entorno productivo (o no).
  • En otros casos, el equipo de desarrollo trabaja de manera iterativa desarrollando las historias de usuario acordadas en cada sprint, el cual tiene SIEMPRE una duración fija. ¿Hay una historia de usuario que no entra en el sprint definido?, pues no pasa nada, la historia de usuario se revisará en la demo del siguiente sprint.

Para que os podáis hacer una idea, de lo que hablo, fijaros en la siguiente figura, e imaginaos un hipotético equipo que trabaja de manera secuencial desarrollando historias (todos pueden desarrollar la misma historia y cuando terminan, pasan a la siguiente).

  • En el primer caso, el equipo deberá fijar de manera variable el sprint, y generalmente tratará de cuadrarlo de manera que se pueda entregar el máximo en cada uno.
  • En el segundo caso, se fija una duración invariable, por lo tanto las historias que no encajen en un mismo sprint deberán ser arrastradas al siguiente sprint.

Como podréis imaginar, cada opción tiene sus ventajas y desventajas. Vamos a analizarlas:

Ventajas de los sprints fijos:

  • Las liturgias se pueden fijar de manera periódica: Todos los equipos se acostumbran a que las liturgias puedan convocarse a la misma hora.
  • Se pueden sincronizar las liturgias de cierre o apertura con reportes mensuales (por ejemplo, si una PMO envía un informe mensual de actividad de proyectos, es sencillo hacer coincidir ambos reportes para incluir los avances de cada sprint).
  • Los equipos se acostumbran a una periodicidad. Todo el mundo sabe que (por poner un ejemplo) cada dos semanas los lunes hay una demo, es más fácil de gestionar la comunicación de cada liturgia y evitamos problemas de agenda.

Cons:

  • No es posible ajustar las entregas en entornos productivos, de las historias de usuario a la duración de cada sprint. Este es el principal problema para muchos, y puede ser crítico en proyectos de desarrollo de producto, donde existen compromisos de entrega cerrados con clientes.
  • Las historias que son desarrolladas en dos sprints afectan al rendimiento de cada sprint, y a sus gráficas ya que no se pueden “partir” los esfuerzos de una historia en dos sprints diferentes.

¿Vosotros? ¿Sois más de sprints fijos o variables? ¿Se os ocurren más ventajas y desventajas? Agradeceré escucharlo en los comentarios.