¿Cuánto debe durar un sprint en Scrum?

Cuando empezamos a utilizar Scrum en nuestra empresa una de las primeras preguntas es: ¿Cuánto deben durar nuestras iteraciones (sprints)? La respuesta como en la mayoría de casos es depende. Pero claro, supongo que esta respuesta no es la que esperabais por lo que voy a intentar daros unas pistas para que con la experiencia podáis decidir cuál será la duración de vuestros sprints.

Primero de todo una observación, el libro blanco de Scrum nos dice que una vez hemos establecido la duración de nuestros sprints está debe mantenerse para todos nuestros posteriores sprints. Esto es cierto ya que de esta forma el equipo podrá tomar medidas cada vez más exactas de su velocidad aprendiendo de los sprints anteriores. Pero esto no quiere decir que pasado un tiempo de estudio el equipo pueda tomar la decisión de variar la duración de sus sprints. Hay que pensar que esta metodología promueve la adaptación y el aprendizaje continuo por lo que no hay que tener miedo de modificar algo si el equipo cree que puede ayudar a mejorar el trabajo ofrecido tanto en forma como en resultado.

Una vez entendido el primer punto, mi opinión es que el sprint debe durar el suficiente tiempo para que permita al equipo dar un resultado que ofrezca un valor real. Pero también hay que tener en cuenta otros factores a la hora de tomar la decisión final.

Si nos encontramos en un momento en que estamos creando un nuevo producto es obvio que queramos tener cuanto antes mejor un producto base que nos permita salir al mercado y después ir añadiendo nuevas mejoras que ofrezcan valor a los usuarios finales. En este caso yo recomendaría utilizar sprints cortos (por ejemplo dos semanas) ya que de esta forma podremos adaptarnos de una manera más ágiles a los cambios inherentes a la creación de un producto.

En cambio si ya tenemos un producto consolidado en el mercado con un número elevado de usuarios la utilización de sprints cortos (seguramente con varios equipos scrum) a la larga puede ser contra producente. La primera idea que nos puede venir a la mente es que con sprints más cortos podremos ofrecer más funcionalidades a nuestros usuarios finales. Pero si nos ponemos en la piel de nuestros usuarios (que al final son nuestros clientes y a quienes nos debemos) que nos estén modificando el producto que utilizamos cada día quizás no nos aporte el valor que esperamos. En estos casos yo recomendaría alargar los sprints de los equipos, una buena medida sería de 3 a 4 semanas.

Espero haber aclarado un poco más esta eterna pregunta y recordad que al final la decisión debe ser una mezcla entre valor aportado, paso sostenible y adaptación a nuestros clientes.

¿Medir las historias de usuario en puntos o en horas?

Esta es la eterna pregunta que se realiza en el seno de un equipo scrum al comenzar a usar esta metodología. Los integrantes del equipo están acostumbrados a dar sus estimaciones en tiempo y les resulta extraño medir su esfuerzo en puntos.

Entonces, ¿Por qué medir las historias de usuario en puntos? En este post intentaré dar una explicación para que podáis convencer a vuestros compañeros de las virtudes de medir las historias en puntos.

En primer lugar uno de los puntos que la metodología basada en Scrum intenta resolver es poder dar un dato fiable de cuanto puede producir un equipo en el plazo delimitado de un sprint. Y este es un punto importante ya que el trabajo será realizado por el equipo y no por personas individuales. Si tenemos en un equipo tres programadores: un programador que calificaríamos como superior a la media, un programador senior y un programador júnior. Es de esperar que si asignamos la misma tarea a los tres programadores el tiempo para resolverla de cada uno será diferente, por ejemplo:

                 El programador junior resolverá la tarea en H horas.

                 El programador senior resolverá la misma tarea en H/2 horas.

                 Y el programador experto resolverá dicha tarea en H/3 horas.

Cogiendo este ejemplo como premisa, cuando nuestro Product Owner asigne esta tarea al equipo deberemos gestionar las diferentes tareas asignándole una persona en concreto para poder dar una estimación clara de cuantas historias podremos realizar en un sprint. Obviamente esto supone un exceso de gestión que nos devuelve otra vez a las metodologías convencionales. Además nos obligará a asignar las tareas complejas siempre a las mismas personas y esto no ayudará a que el resto del equipo madure y coja confianza.

Bueno, ¿Y cómo nos olvidamos de las horas/hombre y empezamos a medir por puntos?.  Empecemos por tener una escala de puntuación base para cualquier tarea. Normalmente se utiliza los puntos asignados en las cartas de poker planning. Los valores de estas cartas son: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 e infinito. Hay que tener en cuenta que la puntuación escogida además de darnos una aproximación de cuanto puede costar desarrollar una tarea también lleva un factor de incertidumbre que aumenta a medida que el número de puntos aumenta.

El valor 0 indica que una historia de usuario es muy simple y que puede estar realizada con un esfuerzo mínimo e infinito indica que la historia es tan compleja que no hay manera de saber cuanto se puede tardar en realizarla (en este caso la historia deberá ser troceada en historias más pequeñas con la finalidad de poder medirlas con más detalle)

El paso más adecuado para empezar a cambiar la forma en que medimos nuestro trabajo sería escoger una historia de usuario que todos consideremos como la más simple (por ejemplo realizar un formulario con tres campos) y preguntar a todos los miembros cuantos puntos de esfuerzo asignarían a esta tarea. El programador experto pensará "bueno esto lo puedo realizar en 3 horas", el programador senior pensará "seguro que necesito 4,5 horas para acabar la historia" y el programador júnior pensará "como mínimo necesito 9 horas para tener la historia terminada". Basándose en sus experiencias en horas intentaran hacer su primera traducción a puntos de historia, después de alguna que otra discusión acordarán una puntuación para dicha historia, por ejemplo 2 puntos.

Bien, en ese momento ya tendremos una historia de referencia. Las siguientes historias podrán basarse en ella. El equipo podrá decidir si la siguiente historia es más o menos difícil que la historia que ya ha puntuado y asignarle una puntuación según la escala definida en las cartas de planning poker. Este proceso se irá realizando hasta que el equipo considere que no puede realizar más historias en un sprint. Llegado a este punto el equipo podrá decir cuantos puntos en total realizará durante el transcurso de dicho sprint.

¿Quiere decir esto que el equipo ya está en disposición de medir las historias en puntos? La respuesta es sí y no. Es un comienzo pero los resultados se irán viendo sprint tras sprint. A medida que el equipo vaya utilizando la metodología irá refinando su forma de puntuar las historias y dará una aproximación más certera en sus previsiones. No podemos esperar que el equipo acierte a la primera en sus predicciones pero con la confianza necesaria y el trabajo constante iremos viendo como el equipo evoluciona y progresa.

Con el tiempo la eterna pregunta ¿Pero que es un punto? irá desapareciendo de nuestros sprint planning. El equipo irá adaptando de una forma natural su forma de puntuar. En ese estadío podremos tener la certeza que cualquier historia de usuario será realizada por cualquier miembro del equipo y que el esfuerzo dedicado será el que el equipo puntuó en el momento de valorar la historia independientemente de quién la realice.

El rol del Scrum Master en un equipo Scrum

Como siempre empecemos por una pequeña descripción que nos proporciona nuestra querida Wikipedia:

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El Scrum Master se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Bueno, ahora que ya tenemos un punto de partida pasemos a desarrollar esta figura dentro de Scrum. La primera pregunta que podría venir a la mente de un neófito es: ¿Por qué el Scrum Master no es un líder?  Buena pregunta, como digo siempre las cosas han de hacerse paso a paso. Un equipo scrum sin un líder establecido es el estadío ideal pero para llegar hasta este punto hay que recorrer un largo camino donde tanto el Scrum Master como el equipo deben ir pasando por unos estados de madurez que les permita llegar a este nirvana existencial. Pasemos a ver en que diferente momentos se encontrará un equipo antes de poder decir que la definición de la Wikipedia es la que define su equipo.

Primer estadío, el Scrum Master yo antes era jefe de proyectos. En este momento el equipo acaba de empezar su singladura, venimos de un modelo tradicional de desarrollo donde existen unos roles y una funcionalidades muy marcadas. El Scrum Master-Jefe de Proyectos reparte el trabajo, define las tareas a implementar y su orden junto con el Product Owner. El equipo suele estar agazapado tras él. La frase "tránquilos ya me encargo yo" está al orden del día. En definitiva el Scrum Master sigue desarrollando su rol de Jefe de Proyectos  pero se ha cambiado el nombre. Empezamos a aplicar los procesos de scrum pero el equipo sigue teniendo la sensación de que reporta su trabajo al Jefe del equipo en lugar de explicar su trabajo al resto del equipo. El Scrum Master modera las reuniones, establece el orden y hay esa sensación de que los miembros del equipo buscan su aprovación cuando exponen su opinión. Como he dicho este es el primer estadío, si te encuentras en él no te preocupes. Es un primer paso y quizás el más habitual, nadie nace sabiendo.

Segundo estadío, ser Scrum Master mola ya no soy el responsable de todo. El equipo empieza a rodar, los miembros empiezan a tomar responsabilidades y el Scrum Master aprende a delegar sobre el equipo y esperando que lo va a hacer bien. Ahora que el Scrum Master empieza a dejar ese viejo vicio de ordeno y mando (command and control) comienza a indagar sobre las maneras de mejorar tanto él como el equipo e intenta aplicarlas en el día a día. En estas pruebas de mejora tanto el equipo como él se retro-alimentan en la motivación porque ven que algunas de las prácticas realmente ayudan a poder mantener un paso sostenible con una mejora en el desarrollo. En este estadío las cosas empiezan a funcionar pero también tiene un riesgo, el Scrum Master puede empezar a pensar que ya ha llegado a su cota máxima de perfeccionamiento. Es importante en este punto que tenga los pies puestos en el suelo.

Tercer (pero no último estadío), ahora ya puedo ser un Agile Coacher. Ahora el equipo empieza a estar un estado en el que su dependecía del Scrum Master suele ser mínima, las cosas funcionan con un alto grado de  satisfacción, los miembros del equipo son seniors y saben tomar decisiones (más o menos correctas) tanto individualmente como en equipo, son capaces de solventar los impedimentos como equipo y de plantear nuevas formas de mejoras. Vamos lo que cualquiera llamaría un equipo de alto rendimiento. En este estadío el Scrum Master empieza a ser una figura que parece prescindible y quizá sea uno de los peligros a los que se enfrenta la persona que decidío tomar este rol. ¿Qué hacer al llegar a este nivel? Podemos tomar dos decisiones, la primera es seguir mejorando tanto a nivel personal como ayudando en la organización o podemos pensar que nuestra etapa en la empresa a llegado a su fin y que debemos ir a otro sitio donde podamos ayudar a otros equipos. ¡Esa ya es tu decisión!.