Logo Spiria

La planification du sprint Agile, la plus importante des cérémonies

8 septembre 2022.

Au cours des deux dernières décennies, le développement Agile est devenu le processus de développement le plus couramment utilisé dans l’industrie du logiciel, Scrum étant son framework le plus populaire. Au cours de ma carrière au sein de diverses entreprises, j’ai remarqué que les gestionnaires utilisaient le développement Agile comme une méthode ou une technique appliquée.

Pourtant, l’agilité est essentiellement une culture de travail qui fait que toute l’équipe se concentre sur la réussite du projet. Cette différence subtile est résumée dans cette citation :

“Il existe deux types d’équipes : celles qui FONT de l’agilité et celles qui SONT agiles.”

Dans cet article, nous nous penchons sur la planification du sprint (Sprint Planning), qui, d’après mon expérience, est souvent la cérémonie considérée comme la moins importante. La planification du sprint est cependant le facteur essentiel pour transformer une équipe dont les sprints échouent en une équipe performante, où tous les membres s’épanouissent professionnellement et apprécient leur expérience.

Une cérémonie pour la cohésion d’équipe

Dans de trop nombreux cas, la planification du sprint est une courte réunion au cours de laquelle le Product Owner (PO) ou le Scrum Master décide du nombre de Stories (tâches) qui seront incluses dans le sprint, en fonction de la vélocité estimée de l’équipe. Ces réunions ne durent que de 15 à 30 minutes et conduisent généralement à des sprints ratés, à un code de mauvaise qualité, à un désengagement de l’équipe et à une implication fluctuante dans le projet ou sa réussite.

Au contraire, la planification du sprint devrait être la cérémonie des développeurs plutôt que celle du PO ou du Scrum Master. C’est le moment où les développeurs prennent les choses en main dans la perspective du sprint à venir. Le PO et le Scrum Master ne sont pas exclus de la réunion, mais ils doivent comprendre que leur influence doit rester limitée :

  • Le PO répond aux questions si nécessaire.
  • Le Scrum Master veille aux bonnes pratiques.

Vers un sentiment d’appropriation

En prenant le contrôle de la planification du sprint, les développeurs cultivent un sentiment d’appropriation qui mènera à l’engagement, à la responsabilisation et à l’imputabilité. Ce changement n’est pas dû à des restrictions, à une pression hiérarchique ou à une appréhension, mais au fait que l’équipe s’engage volontairement dans la livraison, et que les gens veulent intrinsèquement tenir leur parole et réussir à créer des produits de qualité supérieure. Le sprint est l’effort collectif de l’équipe, et l’équipe veut évidemment en être fière. Toutes les pratiques dont nous parlons plus loin dans cet article contribuent à développer et à ancrer cet état d’esprit.

Comme mentionné précédemment, la planification du sprint pour de nombreuses équipes consiste principalement à sélectionner un ensemble de Stories pour atteindre un nombre donné de points pour le sprint. Cependant, le but de cette cérémonie est d’assurer la réussite du sprint en impliquant l’équipe et en évitant les erreurs de communication. Pour réduire au minimum le risque, l’équipe doit avoir une compréhension partagée de chaque Story en matière de :

  • ce qui doit être accompli ;
  • quel devrait être son développement ;
  • combien de temps cela devrait-il prendre.

Privilégier le temps aux points

Pour réduire le risque, la méthode la plus simple est de permettre à l’équipe de diviser chaque Story en sous-tâches avec une estimation de temps. Cette méthode est bénéfique pour l’équipe et le sprint à plusieurs égards :

  • Faire la liste des sous-tâches d’une Story permet à toute l’équipe de voir ce qui doit être fait et comment. Les nouveaux membres de l’équipe apprendront rapidement comment les choses fonctionnent, et chacun d’entre eux peut prendre une tâche et la terminer de manière satisfaisante. La connaissance commune de l’équipe augmente.
  • L’équipe peut et doit remettre en question les sous-tâches ajoutées à une Story pour s’assurer que la solution envisagée est la meilleure. La remise en question et l’amélioration des sous-tâches permettent à toute l’équipe de participer et améliorent les connaissances, la cohésion, l’engagement et la confiance au sein de l’équipe.
  • Estimer le temps de chacune des sous-tâches permet de s’assurer que :
    • La charge de travail réelle s’adaptera à la main-d’œuvre disponible.
    • Les malentendus sont détectés : si deux développeurs arrivent à une estimation différente, c’est probablement parce qu’il y a une différence dans leur compréhension de ce qui doit être accompli et de la façon dont cela doit être fait. La résolution de ce malentendu à un stade précoce évitera que la tâche doive être recodée ou corrigée ultérieurement.
    • Le suivi du temps qui montre la progression du sprint révélera immédiatement tout problème de développement. Il est presque impossible de détecter les problèmes du sprint en suivant à l’aide de Story Points la progression du sprint.

Le suivi de la progression d’un sprint en utilisant le temps des sous-tâches offre un avantage majeur par rapport au suivi en utilisant les Story Points. Comme les tâches sont complétées vers la fin du sprint et que les Story Points ne sont retirés que lorsque la tâche est achevée, tout problème ne devient visible que lorsqu’il est trop tard pour gérer la situation, comme l’illustre le schéma ci-dessous (à gauche, le déroulement d’un sprint réussi, à droite, celui d’un sprint qui échoue).

Typical Sprint.

D’un autre côté, lorsque nous suivons le temps passé dans les sous-tâches, nous remarquons que le “burndown” diverge de la ligne idéale dès qu’une tâche prend plus de temps que prévu. L’équipe peut résoudre le problème de manière proactive et constructive. Cela aide le moral de l’équipe : plutôt que de subir un échec à un moment où rien ne peut être fait, l’équipe peut agir et décider comment minimiser l’impact sur le sprint. Ce qui renforce l’esprit d’équipe, le sentiment de contrôle et l’engagement à réussir.

Une occasion de grandir ensemble

Même si un sprint se termine par un échec, en fin de compte, le résultat sera positif, car l’équipe a travaillé ensemble pour atteindre un objectif et a appris de ses erreurs. L’échec doit toujours être traité comme une occasion d’améliorer et de renforcer l’équipe, et non comme une source d’amertume et de récriminations.

Conclusion

La planification d’un sprint n’est pas une cérémonie pour décider quelle Story mettre dans le sprint, mais une cérémonie pour construire l’esprit d’équipe, créer l’engagement et la responsabilité, et planifier le succès. Quelques heures consacrées à la planification d’un sprint sont toujours un investissement rentable pour la réussite d’un projet.