J’ai décrit les différences entre la planification de la vélocité et de la capacité dans un article précédent, mais dans cet article, je partage l’approche de la planification des sprints qui s’est avérée efficace pour mes équipes. En partageant cette approche, je ne veux pas dire que c’est la vérité absolue. Je crois fermement que chaque équipe devrait expérimenter et trouver l’approche qui fonctionne le mieux pour elle. J’espère que les informations contenues dans cet article vous donneront des idées pour vos expérimentations.
Nous divisons nos réunions de planification en plusieurs parties :
- Le propriétaire du produit propose l’objectif
- L’équipe comprend sa capacité
- L’équipe décompose les histoires (story)
- L’objectif final est choisi
J’ai vu des équipes sauter certaines de ces étapes. Mes équipes ont connu des étapes où nous avons sauté le calcul de la capacité et n’avons pas estimé les sous-tâches à l’heure. Lorsque vous avez une équipe dont la plupart des développeurs travaillent ensemble depuis plus d’un an et qu’ils travaillent sur le même produit, alors l’équipe est en mesure de comprendre ce qu’elle peut fournir en regardant simplement les histoires.
Mais les nouvelles équipes ou les équipes qui travaillent sur un nouveau produit avec quelques inconnues ont généralement besoin de faire une planification détaillée de la capacité en même temps que la planification de la vélocité.
Ne considérez donc pas ces étapes comme gravées dans le marbre et essayez de les adapter aux besoins de votre équipe.
Le propriétaire du produit propose l’objectif
Chaque réunion de planification a sa préparation : le travail que fait le propriétaire du produit. Il comprend les éléments suivants :
1. Définir l’objectif du prochain sprint
Il s’agit du prochain incrément que l’équipe doit livrer. L’objectif représente la valeur que les utilisateurs obtiendront après le succès du sprint. J’ai vu des équipes se fixer des objectifs comme « sortir la version n.n.n. du logiciel ». Ce n’est pas un bon objectif, car il ne représente pas ce que nos utilisateurs vont réellement gagner.
Nous définissons généralement les objectifs comme des histoires du type « Les utilisateurs seront en mesure d’accomplir quelque chose », et celles-ci représentent vraiment le résultat exact que nous aurons pour nos utilisateurs finaux.
C’est très important, car l’équipe doit avoir une compréhension claire de l’étendue du travail qu’elle doit fournir dans le sprint. En outre, l’objectif doit indiquer le seul résultat que les utilisateurs obtiendront du point de vue de la fonctionnalité, et il doit éviter d’inclure une approche technique déterministe de la façon dont les utilisateurs obtiennent la valeur. L’équipe peut être confrontée à des obstacles qui modifient son approche technique, mais qui lui permettent d’obtenir le résultat souhaité pour les utilisateurs.
2. Préparer le backlog
Toutes les histoires qui doivent être complétées pour atteindre l’objectif sont incluses dans le backlog de sprint. Le propriétaire du produit s’assure que le backlog du sprint contient des histoires dont le total des story-points est légèrement supérieur à la vélocité moyenne de l’équipe.
L’équipe comprend sa capacité
Nous utilisons le calculateur de planification de la vélocité et de la capacité que j’ai crée, qui nous aide à comprendre notre allocation et notre capacité disponible. Voici les mises à jour que nous faisons sur cette feuille :
- Mettez à jour les cellules roses des colonnes C ; assurez-vous que nous excluons les réunions, par exemple, si nous savons que nous avons un jour férié, alors ajoutez 1 dans la cellule C17.
- Pour chaque développeur, mettez à jour le % de contribution et les jours de congé. La contribution est utilisée pour les cas où la personne d’astreinte aura 0% de contribution à un sprint, ou peut-être que nous avons un nouvel embauché avec 0% de contribution, mais un autre développeur aidera à l’accueil, donc nous aurons 70% de contribution au sprint.
Après cela, nous connaîtrons la capacité (heures disponibles) pour chaque rôle – mais je voudrais faire une pause et souligner que votre objectif devrait être d’avoir un seul rôle, car la meilleure équipe Scrum est celle où presque tous les ingénieurs peuvent travailler de manière interchangeable. J’ai constaté une énorme amélioration des performances de mes équipes lorsque nous sommes arrivés à un stade où tout le monde faisait tout : tester, développer et aider le propriétaire du produit à définir les histoires. Cela peut paraître bizarre, mais je vais essayer de rédiger un autre article sur ce sujet.
L’équipe décompose les histoires
À ce stade, l’équipe examine chaque histoire en commençant par la plus prioritaire. Pour chaque histoire, l’équipe fait un brainstorming et définit les sous-tâches de l’histoire qui doivent être achevées pour répondre à la définition de ce qui est fait pour l’histoire.
À mon avis, c’est l’une des choses les plus importantes à maîtriser. Il faut faire la bonne ventilation des histoires et donner des estimations horaires aux sous-tâches. Même dans le cas d’une équipe forte qui sait ce qu’elle peut livrer sur la seule base de la vélocité, je suggère toujours fortement de faire une ventilation des tâches en sautant les estimations horaires des sous-tâches.
Lorsque l’histoire est décomposée en sous-tâches, mettez à jour le calculateur de vélocité et de planification des capacités pour indiquer les heures de chaque rôle. Comme la feuille n’est qu’un calculateur qui doit être un outil d’aide, vous n’avez pas besoin de copier toutes les histoires une par une, mais assurez-vous simplement de faire la somme de toutes les heures pour chaque rôle.
Dans chaque sprint, il y a toujours du travail à faire qui n’est pas lié à une histoire. Par exemple, vous avez des problèmes à résoudre ou quelque chose à examiner. Les estimations horaires de ces tâches / problèmes sont également ajoutées à la feuille.
Vous continuez à ajouter des sous-tâches et des problèmes jusqu’à ce que l’un des rôles n’ait plus d’heures disponibles. C’est le bon moment pour discuter de ce qui peut être fait, par exemple si d’autres rôles peuvent prendre en charge le travail du rôle qui n’a pas plus de capacité.
Par exemple, imaginez que vos ingénieurs backend soient complets, mais que vous ayez un autre projet qui nécessite un travail backend. C’est le moment idéal pour discuter avec les développeurs frontaux et voir s’ils peuvent prendre et livrer l’histoire entière.
Il en va de même pour le rôle d’assurance qualité. Lorsque le service d’assurance qualité n’a pas plus de capacité, d’autres ingénieurs doivent intervenir et aider aux tests.
L’objectif final est choisi
Lorsque les tâches sont réparties et que les capacités de l’équipe sont utilisées, l’équipe se penche à nouveau sur l’objectif. À ce stade, elle peut vouloir modifier l’objectif. Par exemple, peut-être que l’équipe n’a pas pu prendre toutes les histoires ou peut-être qu’elle a eu plus de capacité et a dû inclure une autre histoire dans le sprint à partir du backlog de produit. C’est donc le moment où l’équipe s’engage sur l’objectif.
En guise d’indication, je peux dire qu’il n’est pas obligatoire que toutes les histoires du sprint fassent partie de l’objectif. L’objectif peut représenter ~80% des histoires dans le backlog du sprint.
Conclusion
Je suggère de faire la planification en quatre étapes principales :
- Le propriétaire du produit présente le backlog du sprint et décrit le prochain incrément que l’équipe doit livrer.
- L’équipe comprend sa capacité.
- L’équipe divise les histoires en sous-tâches. Donne des estimations horaires aux sous-tâches et aux problèmes qu’elle a inclus dans le sprint.
- Tout le monde regarde à nouveau les objectifs, s’adapte au travail qu’il a effectué et s’engage à atteindre l’objectif.
Cette approche a bien fonctionné pour mes équipes au cours des deux dernières années, et j’espère que vous trouverez des points utiles pour améliorer vos réunions de planification. Mais une fois encore, je tiens à souligner que rien n’est gravé dans la pierre et que vous devez adapter les choses aux processus de vos propres équipes.
