Un bon rythme pour un projet

En principe, dans Scrum, tout se passe au sein des Sprints individuels. On ne peut pas accomplir de tâches "en dehors d'un Sprint". Et pourtant, il existe une exception possible.

Le rythme 6 x 2 + 1

Depuis des années, j'utilise ma méthode 6 x 2 + 1 comme rythme de Sprint. Cela signifie six sprints de deux semaines suivis d'un sprint d'une semaine. Cette idée m'est venue il y a quelques années, lors d'une réunion avec le directeur général et un collègue du département marketing.

Nous parlions du prochain trimestre et de ce que mon équipe pourrait livrer. Le collègue du marketing m'a demandé si nous aurions besoin de six ou sept sprints. Il savait déjà qu'avec des sprints de deux semaines, nous avions toujours besoin de six ou sept sprints (selon le début du trimestre).

Pour répondre à cette question, j'ai compté les derniers vendredis de chaque sprint : 8 octobre, 22 octobre, 5 novembre, 19 novembre. Est-ce que novembre a 30 ou 31 jours ? Alors que je comptais les mois sur mes phalanges, j'ai décidé que nous fixerions six sprints par trimestre.

Cependant, avec six sprints de deux semaines, il restait une semaine par trimestre. Comment devions-nous utiliser cette semaine ? J'ai décidé de laisser les membres de l'équipe en décider. Après tout, ils se plaignaient depuis longtemps de ne pas avoir assez de temps pour le refactoring et d'autres tâches techniques dont ils n'arrivaient pas vraiment à convaincre le Product Owner. Ils avaient donc maintenant une semaine par trimestre où ils pouvaient décider eux-mêmes sur quoi travailler.

Convaincre les Product Owners de cette idée n'a pas été difficile. Je leur ai expliqué que les membres de l'équipe continueraient à travailler de manière productive sur le projet pendant cette période, mais qu'ils pourraient simplement décider eux-mêmes sur quoi exactement. J'ai également expliqué aux Product Owners que l'équipe les solliciterait moins pendant cette semaine. Ils auraient ainsi plus de temps pour la recherche et d'autres choses pour lesquelles ils n'avaient habituellement guère le temps.

C'était génial. Aux équipes, j'ai dit que je faisais tout cela pour elles. Aux Product Owners, j'ai dit que je le faisais pour eux. Mais en réalité, je l'ai fait principalement parce que c'était la solution la plus simple à mon problème de calcul.

Avantages de ce rythme

Chaque trimestre, il y avait une semaine de marge pour chaque projet. Quand les délais ne pouvaient pas être respectés, la treizième semaine pouvait être utilisée dans le cadre d'un Sprint normal. L'équipe pouvait alors utiliser la dix-septième semaine ou une autre semaine ultérieure pour ses tâches de choix.

Peu importait aux membres de l'équipe quelle semaine ils obtiendraient finalement. L'essentiel était d'avoir une semaine par trimestre où ils pouvaient décider eux-mêmes sur quoi travailler.

Pour certaines équipes, la treizième semaine avec cette approche 6 x 2 + 1 se situe en dehors des Sprints. La plupart continueront cependant à appliquer Scrum. Ils organisent alors des Sprint Planning et des Review Meetings très simples et courts. Certains continueront même à faire des Daily Scrums – simplement pour entendre ce sur quoi les autres travaillent.

Mais il y a aussi des équipes qui ne travaillent pas du tout avec Scrum cette semaine-là. C'est acceptable – même si personnellement je préfère organiser au moins de courtes réunions. C'est donc la seule fois où certains travaux peuvent être effectués « en dehors d'un Sprint ».

Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en français.

User Stories

=> Tu trouveras ma structure préférée pour les User Stories dans cet article.

Établissement des priorités

=> Découvre comment définir les bonnes priorités en tant que Product Owner avec "Maintenant" et "Plus tard".