Business : « Pourquoi ne pouvons-nous pas planifier les sprints avec précision et rapidité? »

Mon collègue PST, Glaudia Califano, et moi étions assis dans un café (à un moment avant le verrouillage actuel en raison de Covid-19). Nous avions convenu de rencontrer un analyste d’affaires qui nous avait contacté pour discuter de Scrum et Agile. Nous ne sommes jamais trop occupés pour continuer à prendre un café, nous avons donc accepté de nous rencontrer et de discuter.

Une fois que nous nous sommes installés avec nos lattes et macchiato (je suis généralement un blanc plat, mais c’est toujours un petit macchiato au caramel avec du lait maigre pour Glaudia, juste au cas où vous auriez besoin de le savoir!) et a fait un petit discours Scrum, l’analyste d’affaires est venu sur une des choses qui l’avaient vraiment dérangé.

« Notre problème est que nous ne pouvons pas planifier les sprints avec précision à la vitesse », a-t-il déclaré. « Certains Sprints, notre vitesse est vraiment élevée, dans d’autres, nous réalisons à peine quelque chose. »

Il pourrait y avoir de nombreuses raisons à la description de notre nouvel ami. Nous devions en savoir plus sur le contexte. Peut-être que cette équipe avait juste besoin de temps pour comprendre ce que leur mesure de vitesse signifiait pour eux (ils utilisaient des points d’histoire). Les choses se stabiliseraient avec le temps et elles arriveraient à une gamme de vitesse plus prévisible. Ou, peut-être que l’équipe Scrum a souffert de l’instabilité de ses membres, les membres de l’équipe étant entrés et sortis, empêchant l’équipe de trouver les meilleures façons de travailler les uns avec les autres.

En creusant plus profondément, nous avons découvert que l’équipe en question avait travaillé ensemble pendant plusieurs sprints, suffisamment longtemps pour comprendre ce que leurs points d’histoire signifiaient pour eux, et l’équipe était restée stable pendant cette période.

Nous avons continué à poser des questions. « Les objectifs de sprint sont-ils atteints? » était le suivant. Après tout, dans Scrum, c’est l’objectif de sprint qui devrait être l’objectif de l’équipe de développement, ne pas atteindre une vitesse particulière ou obtenir un ensemble d’éléments de backlog de produit.

Cela a commencé une conversation intéressante et un modèle que nous voyons couramment émergé; les équipes n’ayant pas défini d’objectif de sprint lors de l’événement de planification de sprint. Bien sûr, nous avons vu des équipes prévoir qu’un ensemble particulier de PBI sera fait, mais ce n’est pas la même chose que de créer un objectif de sprint qui indique clairement ce résultat sera atteint lorsque l’objectif sera atteint. Les objectifs de sprint doivent être élaborés par l’équipe Scrum en collaboration. L’équipe de développement a le dernier mot sur les PBI qu’elle prévoit pour le sprint pour satisfaire l’objectif du sprint. Le but de l’achèvement des PBI est que les objectifs de l’équipe Scrum soient atteints.

« Les PBI se font-ils dans un Sprint? » était notre prochaine question. Selon l’analyste d’affaires, ils étaient en bonne position dans la mesure où ils avaient une définition de Terminé et qu’ils avaient donc une compréhension claire et partagée de ce que cela signifiait pour les PBI d’être complets. Ce qu’il a ensuite révélé cependant, c’est que très souvent, les PBI prévus pour le sprint pendant la planification du sprint n’étaient pas toujours terminés pendant le sprint, et étaient généralement reportés dans le prochain sprint.

Se mettre au «fait» à la fin de chaque sprint est le but de Scrum. Lorsque les équipes ne sont pas en mesure de le faire, Scrum fournit en fait l’occasion à l’équipe Scrum d’inspecter ce qui l’empêche de le faire. Il se peut que l’équipe ait trop à faire à la fois, ou que les PBI soient trop grands ou définis de manière vague. Quelle que soit la raison, si une équipe Scrum est incapable de faire régulièrement des choses dans un seul Sprint si elle finit par remettre régulièrement des éléments dans le Product Backlog ou les reporter de Sprint à Sprint, cela va ajouter de la complexité à essayer planifier les sprints en fonction de la vitesse car les nombres sont susceptibles de fluctuer énormément. Il y a toute une série d’autres raisons (et plus importantes) pour lesquelles la réalisation de chaque Sprint est une partie si centrale de Scrum, mais je n’entrerai pas dans les détails ici.

En plus des éléments qui retournaient au Product Backlog, nous avons posé des questions sur les éléments relatifs à ceux que l’équipe pensait avoir été effectués. Ce que nous recherchions ici, c’est la qualité. Qu’il s’agisse de défauts échappés, de dettes techniques ou simplement de fonctionnalités publiées qui ne répondaient pas aux attentes des clients, le travail qui revient à l’équipe de développement va ajouter de la complexité et perturber les plans, surtout si ces éléments arrivent directement dans le Sprint. plutôt que comme de nouveaux PBI sur le Backlog Produit. Au lieu d’accepter cela comme normal, la vraie question que l’équipe Scrum devrait se poser est: « que peut-on faire pour éviter que ces problèmes ne se produisent en premier lieu? »

La vitesse peut être un indicateur utile en tant que guide des performances passées de l’équipe de développement. C’est, cependant, une pratique complémentaire dans Scrum et comme tout outil, il a ses limites. Il ne convient pas à toutes les équipes et à toutes les situations, comme celle ici où la vitesse de l’équipe varie beaucoup. Une alternative à la planification de sprint basée sur la vitesse est la planification de sprint basée sur la capacité.

Nous avons expliqué à notre ami comment fonctionnait le Sprint Planning basé sur la capacité. Commencez par déterminer approximativement la capacité dont vous vous attendez pour le Sprint. Par exemple, votre Sprint peut durer 2 semaines et vous avez 5 membres de l’équipe de développement. Une chose que nous faisons est de supposer 6 heures productives par jour. Cela nous donne donc 10 jours x 5 personnes x 6 heures par jour – 300 heures de capacité. Lors de la planification du sprint, nous demandons à l’équipe s’il y a d’autres drains attendus sur notre temps, tels que des personnes ayant réservé des vacances ou d’autres réunions dans le calendrier.

Comme l’équipe de développement décompose les PBI en tâches lors de la planification de sprint (en aucun cas une méthode de travail prescrite par Scrum, mais une pratique complémentaire courante néanmoins), elle estime les tâches en heures. La planification se poursuit jusqu’à ce que l’équipe soit à court d’heures. Bien sûr, nous nous attendons à ce qu’une nouvelle complexité se révèle pendant le Sprint, nous ne pouvons donc planifier que jusqu’à ⅔ de la capacité disponible. Ce n’est pas parfait, et pas pour tout le monde, mais nous avons constaté que lorsque nous avons utilisé la planification de sprint basée sur la capacité, l’équipe de développement réfléchit encore plus profondément à ce qu’elle doit faire pendant le sprint et se retrouve avec des prévisions de sprint plus réalistes.

Pourquoi est-il important de faire des prévisions Sprint précises de toute façon? Scrum est un cadre pour traiter des problèmes complexes, et les équipes Scrum qui peuvent atteindre une cadence où leurs objectifs sont régulièrement atteints vont instaurer plus de confiance, gérer les attentes des parties prenantes et gérer cette complexité de manière durable.

Nous avons terminé notre café et nous sommes séparés, notre nouvel ami bourdonnant de nouvelles idées à essayer avec le reste de son équipe Scrum. Bien que cela n’ait pu être que les effets de la caféine!