(English follows)

Quelle longueur devrait avoir nos sprints?  1, 2, 3 ou 4 semaines?  Toutes les équipes Scrum et les organisations Agiles se posent cette question et, dépendamment du contexte, certaines organisations peuvent laisser les équipes ou leur imposer un rythme standardisé. Regardons les deux côtés de la médaille afin de comprendre pourquoi les sprints de 3 semaines sont OK… jusqu’à ce qu’ils ne le soient plus.

La grosseur, ça compte

Prenons un petit détour pour expliquer comment les sprints courts donnent plus de contrôle à l’équipe Scrum pour adapter et guider le projet vers un atterrissage en douceur. Imaginez un projet de 4 mois.  Combien de points d’adaptation pouvons-nous avoir pendant cette période?  Si vous avez livré plusieurs projets Scrum, vous savez que les 2-3 premiers sprints servent au ‘décollage’ et à la stabilisation alors que les 1-2 derniers sprints servent à ‘atterrir’ et fermer le projet.  Sachant ceci, à moins que votre équipe de développement soit une bande de vétérans unis, un projet de 5 sprints ne donnera pas le temps à votre vélocité (d’effort) de devenir prévisible.   Une autre façon de calculer le nombre de points d’adaptation d’un projet Scrum est de retirer la première et la dernière planification de sprint.  Sans mesure précédente, la première planification n’adapte rien alors que la dernière planification est plutôt utilisée pour fermer les travaux et ne prendre aucun risque.  Si on regarde un projet de 4 mois, ceci ne donne que 2 points de contrôle pour des sprints de 4 semaines et 6 points de contrôle pour des sprints de 2 semaines.  Donc, des sprints courts, c’est mieux.

En défense de la liberté

La flexibilité de pouvoir choisir la longueur de sprint est un des avantages de Scrum.  Pour l’équipe Scrum, choisir et adapter cette variable fait partie de leur auto-organisation, permettant de balancer la grosseur des incréments avec la fréquence d’itération.

En défense de la standardisation

À l’autre bout du spectre, imposer un longueur de sprint a comme avantage de synchroniser les sprints, ouvrant ainsi une fenêtre d’opportunité pour le personnel flottant (ne faisant pas partie des équipes « noyau ») de transférer d’équipe.  C’est aussi un moment où l’avancement global peut être mesuré simultanément.  Ceci est particulièrement important pour comprendre l’avancement des projets/programmes composés de plusieurs équipes.

Comment avoir le meilleur des deux mondes?

…

En éliminant les sprints de 3 semaines

Si toutes les équipes limitent leur choix de longueur de sprint à 1, 2 ou 4 semaines, il est alors possible de synchroniser la fin de tous les sprints à la semaine #4.  Bien sûr, pour que cela fonctionne, certaines équipes devront ajuster leur cadence en ajoutant ou soustrayant une semaine à l’un de leurs sprints.  Une fois cette réinitialisation faite, les équipes auront un sprint synchronisé à toutes les 4 semaines.

Alors, à moins de vouloir synchroniser vos sprints, il n’y a pas de problème à faire des sprints de 3 semaines.  Sinon, ils deviennent le mal incarné.

Phillipe Cantin

—

Why did we stop doing 3-week sprints?

How long should our sprint be? 1, 2, 3 or 4 weeks? Every Scrum team and Agile organization will eventually ask that question. Depending on the context, some organizations will let the teams decide, while others will impose a standard pace.  Let’s take a look at both sides of the coin and explain why 3-week sprints are OK… until they are not.

Size matters

Let’s take a little detour to see how short sprints give more control points to the Scrum Team for adapting and steering the project toward a soft landing.  Imagine a 4-month project. How many points of adaptation can we have during this period?  If you have delivered many Scrum projects, you know that it takes 2 to 3 sprints to ‘take off’ and stabilize, whereas the last couple of sprints are used for landing and closing the project. Given that, unless your Development Team are a tight-knit band of veterans, a 5-sprint project will not give you enough time to gain a predictable effort velocity.  Another way of calculating the number of adaptation points in a Scrum project it is to remove the first and last sprint plannings.  By having no previous measure, the first planning is not adapting anything while the last planning is normally used to close things with zero risk. If we look at a 4-month project, it only gives you 2 points of control for 4-week sprints, and 6 points of control for 2-week sprints. Therefore, shorter is better.

In defence of freedom

The flexibility of being able to choose the sprint length is one of the many advantages of Scrum.  For the Scrum Team, choosing and adapting this variable is part of their self-organization, enabling them to balance the increment size with iteration frequency.

In defence of standardization

At the other end of the spectrum, imposing a sprint length has the advantage of synchronizing the sprints, which opens a window of opportunity where floating personnel (employees who are not part of a core team) can hop from one team to another.  It is also a moment where overall progress can be measured simultaneously. That is especially important when we want to be able to follow the progress of projects/programs composed of several teams.

How can we get the best of both worlds?  

…

By getting rid of 3-week sprints.

If all the teams limit their sprint length to 1, 2 or 4 weeks, it is then possible to synchronize the end of all the sprints at week #4.  Of course, some of the teams will have to adjust their sprint cadence by adding a week or subtracting a week from one of their sprints. After this simple ‘reset’, everybody will reach a synchronized sprint every 4 weeks.

So, unless you want to synchronize your sprints, 3-week sprints are totally fine. Otherwise, they are pure evil.

Phillipe Cantin