Pourquoi il ne devrait PAS y avoir de Backlog de Release
Auteur : Mike Cohn
Source : Why There Should Not Be a "Release Backlog"
Date : 07/02/2009
Traducteur : Fabrice Aimetti
Date : 30/06/2012
Traduction :
Je n'avais pas entendu parler de "backlog de release" depuis plusieurs mois, mais le terme est réapparu dans trois conversations la semaine dernière. Je souhaiterais donc partager avec vous mes pensées sur le fait qu'une équipe utilisant une gestion de projet agile devrait avoir - ou non - un Backlog de Release en plus des habituels Backlog Produit et Backlog de Sprints (Itérations).
Tout d'abord, laissez-moi clarifier ce que les gens veulent dire lorsqu'ils font référence à un "backlog de release". Un backlog de release est un sous-ensemble du backlog produit, qui est planifié pour la prochaine release, typiquement à un horizon de trois à six mois. Un backlog de release contiendra probablement le même type d'éléments que le backlog produit. Ma préférence irait bien entendu aux user stories. Donc, au moment d'une planification de release, le product owner, avec l'aide de l'équipe et des parties prenantes, va illustrer le backlog produit, sélectionner une quantité de travail de haute priorité, et placer ces éléments dans le backlog de la release. Plus tard, lors de la planification du sprint (itération), l'équipe examinera la release du produit et sélectionnera le travail à réaliser. (Remarquez ici que cela va déjà à l'encontre de la littérature agile qui dit que l'équipe sélectionne les éléments de plus haute priorité pour le sprint à venir à partir du backlog produit).
Je suis opposé à l'usage du backlog de release pour plusieurs raisons :
D'abord, dans tous les projets qui ne sont pas réalisés sous un périmètre fixe contractualisé (et même sans ça), nous ne savons pas exactement quelles user stories ou features seront livrées dans une release. Dire qu'il y a un backlog de release ne garantit pas que toutes les fonctionnalités seront livrées. En plus, cela crée un travail supplémentaire lorsque les éléments font des allers-retours entre le backlog produit et le backlog de release. C'est ce qui arrivera lorsque la vélocité de l'équipe changera (même un peu) de sprint en sprint. Si le backlog de release est censé montrer ce que l’équipe va livrer dans la release, il doit contenir une quantité de travail égale au nombre de points de story (ou jours idéaux) multiplié par le nombre de sprints restants. Si vous avez une vélocité moyenne de 20 et qu'il reste 6 sprints, le backlog de release devrait contenir un travail équivalent à 120 points. Supposons que l'équipe finisse 24 points de travail dans le sprint. Le backlog est maintenant de 96 points (120-24) mais devrait contenir 100 points (5 sprints restant x vélocité moyenne de 20). Les choses deviennent plus difficiles si cette bonne vélocité de 24 augmente la vélocité moyenne de l'équipe à 21. Dans ce cas, le backlog de la release doit contenir 5x21=105 points de travail ; nous devons déplacer 9 points de travail du backlog produit vers le backlog du sprint. S'il y a un backlog de release, ces aller-retours entre le backlog produit et le backlog de release auront lieu à chaque sprint.
Ensuite, introduire un backlog de release génère une confusion supplémentaire. Nous avons déjà surchargé le terme "backlog" avec "backlog produit" et "backlog de sprint". Pourquoi générer davantage de confusion en introduisant un troisième type de backlog, à moins bien sûr qu'il y ait une raison impérieuse de procéder ainsi ?
Enfin, introduire le concept de Backlog de Release rend réellement la tâche difficile pour les product owners, qui vont essayer de trouver les user stories ou features qui sont juste à la limite et qui devront sortir de la release. Lorsque je regarde un backlog produit et que je décompte le nombre de points de story que j'anticipe avoir dans la prochaine release, la chose la plus intéressante pour moi n'est pas forcément l'ensemble des stories qui feront partie de la prochaine release. Ce qui m'intéresse le plus souvent ce sont juste les stories qui sont juste en-dessous de la limite. C'est-à-dire que je m'intéresse aux user stories qui ne feront pas partie de la release. Après tout, nous disons bien que l'un des bénéfices de l'agilité (sur cetains projets, pas tous), c'est notre capacité à décider si nous allons livrer quelques sprints plus tôt (si on a déjà fait beaucoup), à la date prévue, ou alors un ou deux sprints plus tard si nous souhaitons ajouter quelques fonctionnalités avant de livrer. C'est plus difficile avec un Backlog de Release, parce qu'un product owner doit maintenant examiner à la fois le Backlog Produit et le Backlog de Release pour prendre des décisions.
Alors, que puis-je proposer à la place ?
Je préconise que toutes les équipes suivent leur vélocité. Ce qui donne un graphique de ce type :
Ce graphique montre une équipe calculant trois vélocités moyennes :
- une moyenne sur le long terme, définie comme la moyenne des vélocités des huit derniers sprints
- une moyenne pessimiste, définie comme la moyenne des trois plus mauvaises vélocités au cours des huit derniers sprints
- une moyenne optimiste, définie comme la moyenne des trois meilleures vélocités au cours des huit derniers sprints
Vous êtes bien sûr libre de choisir votre propre manière de calculer les vélocités moyennes sur le long terme, pessimiste et optimiste. Celles que je viens de de vous présenter sont celles que je préfère. Nous utilisons ensuite ces vélocités moyennes comme suit :
Sur ce schéma, le backlog produit est illustré à gauche comme un tas de cartes bristols. Nous utilisons les trois vélocités moyennes multipliées par le nombre de sprints restants pour dessiner des flèches qui pointent vers le backlog produit. La zone pointée par ces flèches indiquent la quantité probable de travail qui aura été réalisée d'ici la date planifiée. Notre plan de release est la quantité de travail pointée par les différentes flèches. Plutôt que de passer par un Backlog de Release qui constituerait un nouvel élément de travail sur le produit ou artefact, je présente quelque chose d'équivalent au Backlog de Release avec le Backlog Produit et les flèches qui pointent dessus.
Comme vous pouvez l'imaginer, prédire la vélocité selon un intervalle est probablement beaucoup plus précis que d'utiliser un seul point d'estimation ("notre vélocité est de 31") comme j'ai pu l'entendre de la part de certaines personnes qui géraient un Backlog de Release. De plus, en considérant ainsi les chiffres, vous rendez apparent que la quantité de travail, qui sera réalisée d'ici la fin de la version, changera au fur et à mesure des sprints. Pointer des flèches vers le backlog produit est beaucoup plus facile et utile que de créer un nouvel élément de travail sur le produit, le Backlog de Release.
