Si les besoins peuvent varier d’une entreprise à l’autre, certaines bonnes pratiques peuvent vous aider à optimiser le temps et les efforts de votre équipe. Leur application est gage de l’utilité et de la réussite de ces sessions pour les équipes agiles les plus performantes. Ces bonnes pratiques prennent en charge chaque aspect de la session, de la préparation à la définition des éléments de travail et jusqu’aux techniques de gestion.
Attribuez des responsabilités.
Un affinage du backlog efficace ne se produit pas spontanément et commence bien avant la session. L’absence de préparation adéquate est une cause fréquente d’inefficacité et d’improductivité des sessions. Lorsque tous les participants prennent le temps de se préparer correctement, la session d’affinage passe d’un simple transfert passif d’informations à une session de travail active et collaborative.
L’équipe peut alors approfondir les discussions, résoudre les problèmes et prendre des décisions, plutôt que de perdre un temps précieux de réunion à communiquer des informations de base. Il ne s’agit plus seulement d’apprendre à connaître les éléments, mais de les affiner activement, ce qui est l’objectif principal de la réunion.
- Responsabilités de la ou du responsable produit : la ou le responsable produit doit préparer parfaitement la session, notamment établir un ordre du jour clair, identifier les éléments spécifiques du backlog à aborder pendant la session et recueillir toutes les informations de base, les données ou les commentaires préliminaires des parties prenantes concernées. Il s’agit également de bien comprendre la stratégie globale du projet ainsi que les KPI pertinents pour orienter les discussions sur les priorités.
- Responsabilités des personnes participant au backlog : toutes ces personnes doivent prendre connaissance de l’ordre du jour et lire tous les documents mis à disposition au préalable. Les membres de l’équipe doivent se préparer à discuter de la valeur et des implications des fonctionnalités qu’elles ou ils pourraient proposer, en ayant déjà réfléchi à la façon dont ces éléments s’alignent sur la feuille de route globale du produit, les priorités des parties prenantes et les personas client définis.
Structurez clairement un backlog.
Un backlog monolithique et désorganisé peut rapidement devenir ingérable et prêter à confusion. Les équipes performantes connaissent l’importance d’un backlog clairement structuré et gérable.
- Catégorisation : il est conseillé de diviser le backlog en catégories logiques plutôt que de le présenter sous la forme d’une liste unique interminable. Par exemple, les équipes peuvent maintenir un backlog développement (pour le travail engagé), un backlog produit (pour les fonctionnalités et les améliorations à venir) et un backlog idées (pour les idées brutes, le feedback utilisateur et les résultats des recherches). Cette répartition permet aux équipes de gérer et d’examiner différents types d’éléments en fonction des besoins de l’entreprise.
- Libellé et étiquetage clairs : chaque élément du backlog doit avoir un nom clair, concis et explicite. Un étiquetage cohérent peut faciliter l’organisation et le filtrage.
- Flux d’entrée défini : établissez des workflows clairs pour la capture et l’acheminement des nouvelles demandes, idées, rapports de bugs et autres entrées dans le backlog (ou la section du backlog) approprié. Ainsi, les éléments entrants ne sont pas perdus et peuvent être systématiquement examinés et classés par ordre de priorité.
La catégorisation des backlogs constitue une forme d’architecture de l’information pour le processus de développement des produits, qui réduit la surcharge cognitive de l’équipe et permet aux différentes parties prenantes de se concentrer sur les sections les plus pertinentes pour leurs rôles.
Fractionnez les éléments de grande envergure.
Un défi courant dans la gestion du backlog consiste à traiter des caractéristiques ou des exigences considérables et complexes, souvent dénommées Epics. Dans ce cas, une bonne pratique indique qu’il convient de diviser ces Epics en user stories plus courtes et gérables, pouvant être achevées en un seul sprint.
- Avantages des stories plus courtes : les stories courtes sont moins intimidantes pour l’équipe, plus faciles à comprendre et à estimer avec précision. Elles génèrent plus fréquemment de la valeur ajoutée et facilitent des boucles de feedback plus rapides de la part des utilisateurs et utilisatrices et des parties prenantes.
- Techniques de fragmentation : les Epics peuvent être fragmentées en fonction des rôles, des étapes du processus, des règles commerciales ou des couches techniques. La cartographie des user stories est une technique visuelle qui peut s’avérer particulièrement utile pour identifier les éléments constitutifs d’un parcours d’utilisateur plus large et le décomposer en stories exploitables.
La fragmentation des Epics n’est pas seulement un exercice de raccourcissement des tâches. Il s’agit d’une étape essentielle pour réduire les risques liés au développement et permettre des progrès itératifs réels. Chaque story plus petite représente un incrément testable de fonctionnalité.
Gérez les dépendances.
Rares sont les éléments du backlog qui existent de manière totalement isolée. L’identification et la gestion des dépendances entre les user stories ou les tâches est un aspect crucial de l’affinage du backlog.
- Impact des dépendances non gérées : les dépendances non identifiées ou non gérées sont une source fréquente de perturbations, de goulots d’étranglement et de retards dans les sprints. Une équipe peut commencer à travailler sur une story et se rendre compte qu’elle est bloquée par une autre story non terminée, voire non commencée.
- Identification proactive : lors de l’affinage, les équipes doivent rechercher activement les dépendances. Cela peut impliquer de poser des questions comme : « cette story dépend-elle d’une autre tâche qui doit être réalisée en premier ? » ou « d’autres tâches seront-elles bloquées si cette story n’est pas terminée ? ».
- Visualisation : les dépendances peuvent être visualisées (par exemple, sur une carte de story, un tableau d’enquête ou dans des outils de gestion du backlog) pour aider la ou le responsable produit à ordonner le travail de manière logique et les équipes à coordonner leurs efforts.
Évitez les problèmes courants.
Pour optimiser les avantages de l’affinage du backlog, il est essentiel de reconnaître et de traiter les pièges courants susceptibles d’entraver le processus.
Défi : séances de backlog non planifiées : l’un des problèmes les plus fréquents est de ne pas organiser de sessions régulières ou de ne pas avoir de plan ou d’ordre du jour précis, ce qui mène à une accumulation des backlogs et à des réunions inefficaces.
Solution : établissez un rythme régulier et récurrent pour les sessions d’affinage (par exemple, toutes les semaines ou toutes les deux semaines) et veillez à ce que chaque session ait un ordre du jour préparé avec des points spécifiques ciblés pour la discussion.
Défi : objectifs et portée des user stories non définis : des éléments du backlog vagues, l’absence d’objectifs clairs ou un champ d’application mal défini peuvent entraîner une certaine confusion, des discussions qui traînent en longueur et des difficultés d’estimation.
Solution : veillez à ce que chaque story ait un objectif clair et une proposition de valeur. Appliquez les critères INVEST pour évaluer la qualité des stories et respectez une « Definition of Ready » (DoR) définie par l’équipe avant de considérer qu’un élément est prêt pour le sprint.
Défi : manque de priorisation ou ignorance des dépendances : un backlog non priorisé, ou dont les dépendances ne sont pas identifiées et gérées, peut amener les équipes à travailler sur des éléments de faible valeur ou à rencontrer fréquemment des blocages.
Solution : employez une méthode de priorisation cohérente et transparente. Identifiez activement les dépendances lors de l’affinage et assurez-vous que la ou le Product Owner organise le travail en conséquence.
