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.
No hay comentarios:
Publicar un comentario