Iteraciones / Iterations

Cualquier persona que empiece a leer sobre SCRUM se dará cuenta de la importancia de que las iteraciones (o sprints) tengan una duración determinada a lo largo de un proyecto. Fijar la duración de los sprints es uno de los pocos principios de SCRUM. Por ejemplo, no se puede variar, a medio proyecto, los sprints de 2 a 3 semanas, y después a 2 de nuevo. Crea confusión en el cliente y en el mismo equipo, y no ayuda a establecer un buen ritmo de trabajo.

Ahora bien, algo más complicado es decidir cuál es la mejor duración en cada caso.

Cuando me preguntan qué duración es la adecuada para una iteración SCRUM, siempre respondo que “depende del caso”. Es una respuesta imprecisa, con lo que quiero aprovechar este post para dar mis razones para no aconsejar una duración estándar de un sprint (sin conocer los detalles del proyecto).

Cuando estamos implantando SCRUM por primera vez, mi sugerencia (¡para esto y para tantas otras cosas!) es tomarnos nuestro tiempo entendiendo el entorno. Llegar como consultor expertísimo en SCRUM e intentar aplicar el proceso que te ha funcionado en otras ocasiones a un nuevo “ecosistema” es una receta para el fracaso. Muchas veces, la implantación de SCRUM se servirá de un proyecto prototipo. Considero aceptable variar la duración del sprint después de dicho prototipo (¿para qué nos sirven los proyectos prototipos si no es para probar?). Pero, cuando se haga un despliegue de la metodología a nivel departamental o de toda la compañía (o sea, incluyendo múltiples proyectos), sería adecuado mantener sprints más o menos similares, porque ayuda a una mejor comprensión a nivel organizativo de SCRUM y de cuando esperar resultados.

En general, se debería tener en cuenta:

• Procesos organizativos y entorno


• ¿Es un producto interno o para un cliente externo?


• ¿Qué procesos de autorización existen para ponerlo en producción? Por ejemplo, los complicados procesos que pueden existir en un entorno bancario o en según qué clientes externos, incluyendo departamentos de operaciones, etc.


• Disponibilidad del cliente


• Número de usuarios


• Necesidades de formación cada vez que se lanza una nueva release


• Localización / disponibilidad en general


• Naturaleza de la solución (producto realizado)


• ¿Cuán urgente es la necesidad de nuevas funcionalidades?


• Madurez del equipo de desarrollo


• Conocimiento de SCRUM, cómo de multidisciplinares sean sus miembros, etc.


• ¿Cuál es la capacidad de utilización / reacción / tolerancia de los usuarios a las nuevas iteraciones?

En resumen, no es lo mismo realizar un producto para un grupo de usuarios internos que lo conozcan bien y sólo necesiten una mínima formación que no, por ejemplo, una release de software bancario para un cliente externo en el que son necesarios un par de días de pruebas más formación y documentación para los usuarios, etc. En el primer caso se podría pensar en iteraciones de incluso 1 semana, en el segundo, de 1 mes. Y según mi opinión, ninguna sería más correcta que la otra.

Anyone who starts reading about SCRUM will realize the importance that iterations (or sprints) have a fixed duration during a project. It is one of the few SCRUM principles to maintain a fixed sprint duration. For example, it is not a good idea to have sprints of 2 weeks and, in the middle of a project, change them to 3 weeks, only to change them back to 2 weeks afterwards. It creates confusion in the customers and it does not help to establish a good pace within the development team.

But to decide this sprint duration is somewhat more complicated.

When I am asked about what is the appropriate duration for an iteration in SCRUM, I always reply that "it depends on the case". It's a vague answer, so I will use this post to explain my reasons behind not recommending a standard duration of a sprint (without knowing the details of the project).

When you first implement SCRUM, my suggestion (for this and many other things!) is to take your time and understand the environment. Being hired as a SCRUM coach and try to apply the same process that has worked for you in the past to a new "ecosystem" is a recipe for failure. Many times, the implementation of a SCRUM project will use a prototype. I consider acceptable to vary the length of the sprint after this prototype (why do we use prototypes, if not to experiment?). But, when deploying SCRUM to other departments or even company-wide (i.e., including multiple projects), you should have defined similar sprints. It helps the organisation to understand better how SCRUM works, and what to expect.

In general, when deciding sprint duration, you should consider:

• Organizational processes and environment


• Are you building an internal product or do you have external customers?


• What authorisation processes exist? How do things get deployed into Production? For example, the complicated processes that exist in banking, operation departments procedures, etc.


• Customer Availability


• Number of users


• Training needs whenever a new release is launched


• Location / availability in general


• Nature of the solution (product)


• How urgent is the need for new features?


• Maturity of the development team


• Knowledge of SCRUM, skills and competencies of the members, etc.


• What is the reaction / tolerance of users to new iterations?

In summary, it is not the same to develop a product for a group of internal users who know it well and need basic or no training at all, than building software for external customers who need a couple of days of testing plus training and user documentation, etc. In the first case we could think of 1-week iterations in the second case, 1-month iterations. And in my opinion, one option won’t be more correct than the other.