Une liste de tâches a deux états : faite et non faite. L’objectif est de la vider. Le progrès, c’est des tâches que l’on barre. La liste est un relevé d’obligations, et l’achever est la définition du succès.
Un Backlog est différent dans toutes ses dimensions. Il n’est jamais vide — cela voudrait dire qu’il n’y a plus rien à améliorer ni à ajouter au produit, ce qui est rarement vrai pour quoi que ce soit qui mérite d’être construit. Il n’est pas ordonné par séquence mais par valeur, laquelle peut changer à tout moment : le plus important d’abord, le moins important plus bas. Ce n’est pas un relevé d’obligations mais une carte de possibilités, révisée en continu à mesure que l’équipe apprend ce dont le produit a besoin et ce que les utilisateurs veulent réellement. Et il s’entretient en se redemandant constamment ce qui compte le plus pour les personnes qui attendent le travail.
Ce qu’est réellement le Backlog Refinement
« Backlog Refinement » est l’un des trois composants du Backlog Management — Backlog Inception, Backlog Workshop et Backlog Refinement. C’est la pratique consistant à passer en revue, ordonner, affiner et élaguer régulièrement les éléments du Backlog. Cela sonne comme de l’entretien. C’est en réalité l’une des activités les plus exigeantes intellectuellement en Agile : la conversation continue entre ce que vous savez, ce que vous avez appris et ce sur quoi vous devriez — et ne devriez pas — travailler ensuite.
Un Backlog bien affiné reflète la compréhension actuelle de la valeur. Les éléments du haut (l’objet premier du Backlog Refinement) sont bien définis et prêts à être travaillés. Les éléments du milieu (l’objet du Backlog Workshop) ont assez de forme pour être estimés et discutés, mais pas assez pour que l’on commence à les traiter. Les éléments du bas (l’objet du Backlog Inception) peuvent être des idées brutes — des marque-places pour des choses qui méritent d’être retenues mais pas encore d’être définies en détail, et certainement rien que l’on s’engage à faire, et encore moins pour une date butée. Et ce qui avait du sens il y a six mois, ou même hier, comme interruption hautement prioritaire a pu descendre ou disparaître entièrement à mesure que le produit et ses utilisateurs ont évolué.
Gérer un Backlog comme une liste de tâches, c’est traiter tous les éléments comme également obligatoires, les ordonner par date d’ajout plutôt que par valeur, et mesurer le progrès au nombre d’éléments barrés. Le résultat prévisible : les équipes accomplissent beaucoup de travail qui ne fait pas avancer le produit, parce que la liste était organisée autour de l’achèvement et non de la valeur.
L’incomplétude est le propos
Un Backlog qui bouge sans cesse et ne se vide jamais n’est pas un échec de productivité. C’est un produit sain dans un environnement complexe qui génère plus d’idées et d’apprentissages qu’on ne peut en mettre en œuvre à la fois. La question n’est pas « quand aurons-nous fini ? » — c’est « quelle est la chose la plus utile que nous pourrions faire ensuite ? ». Une liste de tâches se termine. Un Backlog sain respire : il grandit et se réduit à mesure que le produit apprend, et n’est jamais vide, par conception.
Contenu associé
- The Backlog Breakthrough: 3 Essential Practices for Agile and AI Teams — Agile4AI sur YouTube
Commentaires 0