Les meilleurs conseils des experts Scrum et Agile sur la gestion de votre backlog produit

D’abord, définissons clairement ce qu'est un backlog produit. Scrum organise les projets en une série de périodes de travail ciblées appelées Sprints, et chaque sprint dure généralement deux semaines. Avant le début du sprint, l’équipe et le Scrum Master (qui remplit la fonction de coach) créent leur backlog Sprint, qui est une liste de ce qu’ils ont l’intention d’accomplir dans le sprint à venir. 

Le backlog Sprint est tiré du backlog produit plus vaste, qui est une liste complète de toutes les fonctionnalités et fonctions qui doivent être ajoutées au produit. Le Product Owner est chargé de hiérarchiser le backlog produit. (Le Product Owner représente également les besoins du client et des autres parties prenantes et oriente le travail de l’équipe de développement.) Le backlog produit est classé verticalement, de sorte que les tâches les plus importantes sont répertoriées en haut, et l’équipe Scrum sélectionne généralement les éléments du backlog en fonction de leur priorité. Le backlog produit changera et évoluera au fil du temps en fonction des demandes des utilisateurs, des besoins de l’entreprise et des tendances technologiques plus larges.

En outre, vous pouvez également utiliser un backlog produit dans un autre framework Agile appelé Kanban. Bien que le Kanban soit basé sur la limitation du travail en cours (WIP) au lieu d’utiliser des sprints de longueur fixe (Scrum), les informations contenues dans cet article peuvent également être appliquées aux projets Kanban.

Un backlog produit bien construit garantit que votre travail est productif et précieux, que le produit répond aux besoins des clients et qu’il s’aligne sur les objectifs de votre organisation. Tout comme pour votre liste personnelle de tâches à faire, vous devez constamment gérer votre backlog produit. Ce processus est souvent appelé affinement ou nettoyage du backlog produit. Les priorités changent, les tâches sont accomplies et les idées sont rejetées. Sans vous ne mettez pas à jour votre backlog, il sera désorganisé et ne vous aidera pas à rester sur la bonne voie.

Pour créer un backlog produit, certains experts Agile recommandent de commencer par une feuille de route produit. Il s’agit d’un plan stratégique qui offre une perspective à plus long terme pour votre produit.  Roman Pichler, formateur expert en gestion Agile des produits, explique que de nombreux Product Owners et chefs de produit se concentrent trop sur les détails des fonctionnalités dans leurs feuilles de route et pas assez sur la vision d’ensemble. Il a développé un modèle de feuille de route axé sur les objectifs qui met l’accent sur l’objectif du produit et les fonctionnalités nécessaires pour atteindre cet objectif.
 
Bien que votre feuille de route puisse inclure des objectifs à long terme pour plusieurs versions, le backlog produit doit avant tout décrire en détails le travail pour la prochaine version. Les versions futures doivent être placées plus bas et exprimées de façon moins détaillée. Ensuite, prenez les informations de la feuille de route et traduisez-les en tâches et éléments de travail. 

Chaque produit doit avoir son propre backlog. Si votre produit est assez large ou fait partie d’une suite de produits interdépendants, il peut être difficile de déterminer ce qui constitue un produit. L’expert Agile Kenneth Rubin, consultant chez Innolution, explique que l’objectif est de réduire le nombre d’équipes de composants et de backlogs composants, si bien qu’il préfère utiliser un seul backlog chaque fois que c'est possible. Cependant, pour les projets de très grande envergure avec des dizaines ou des centaines d’équipes, ce n’est pas pratique, et dans ces cas, les backlogs hiérarchiques peuvent être utilisés avec un backlog pour les fonctionnalités à grande échelle et un backlog distinct pour chaque domaine de travail connexe.

Les éléments de travail du backlog produit sont souvent exprimés dans ce qu’on appelle des récits utilisateurs (user stories), une description du fonctionnement de la fonction du point de vue de l’utilisateur. Un récit utilisateur est assez court pour être accompli au sein d’un sprint. 

Chuck Kroll, un coach Agile qui a formé des équipes chez Fidelity Investments, recommande une formule traditionnelle pour les récits utilisateurs :  « En tant que (type d’utilisateur, tel que client), je veux (objectif) pour (raison) », explique Kroll. « Cela indique clairement qui utilisera la fonction, ce qu’elle implique et quelle valeur commerciale elle offre ». 

User Story vs. User Epic : À quel point les éléments du backlog doivent-ils être détaillés ?

Un récit beaucoup plus long est appelé « épique » et sa réalisation peut nécessiter plusieurs sprints. Les epics doivent être divisés en stories avant de commencer le travail.

Mike Cohn, fondateur de Mountain Goat Software qui propose des formations Agile et Scrum, propose cet exemple d’epic : une entreprise hôtelière souhaite qu’un système détermine la somme maximale qu’elle peut facturer pour une chambre d’hôtel en fonction de variables telles que les tarifs des concurrents, la saison, etc. « En tant qu’opérateur hôtelier, je veux définir le tarif optimal pour les chambres de mon hôtel. » Cela se décompose en récits utilisateurs comme « En tant qu’opérateur hôtelier, je veux définir le tarif optimal pour les chambres en fonction des tarifs de l’année précédente » et « En tant qu’opérateur hôtelier, je veux définir le tarif optimal pour les chambres en fonction de ce que facturent les hôtels comparables au mien ».

Lorsque vous préparez des récits utilisateurs pour le backlog produit, les éléments prioritaires supérieurs doivent comporter plus de détails pour aider l’équipe à les exécuter avec précision. Il peut s’agir de diagrammes montrant le flux de travail d’une fonction ou une description de ses détails. 
« Le conseil le plus important que beaucoup négligent est que les éléments du backlog produit n’ont pas tous besoin du même niveau de détail », commente Cohn. « Les éléments qui relèvent du prochain sprint doivent être modérément détaillés. Plus les éléments sont lointains, moins ils doivent être détaillés ».

Imaginez le récit utilisateur suivant : En tant que visiteur du site Web, je veux pouvoir acheter un billet d’avion au prix le moins cher proposé à l'aéroport de mon choix ou par les aéroports à proximité. Étant donné que cela se trouve en haut du backlog produit, vous devez ajouter des détails à cette user story, comme : la fonctionnalité doit vérifier les tarifs de tous les aéroports à moins de 150 km ; elle doit me donner la possibilité de trier les tarifs par distance de l’aéroport de premier choix et par prix. 

Pichler recommande que le cycle de vie des produits soit important pour décider de la granularité du backlog produit. Les jeunes produits devraient avoir des backlogs plus courts et moins détaillés, qui vous permettent d’expérimenter de nouvelles idées et de changer fréquemment le produit pour l’optimiser. D’autre part, les produits plus anciens et plus stables bénéficient d’un backlog plus détaillé car vous êtes davantage en mesure d’anticiper l’évolution du produit.

Le cycle de lancement est un autre facteur de votre backlog produit. Lorsque vous commencez à travailler sur une nouvelle version ou une grosse sortie, il y a plus d’inconnues et ce que vous apprenez entraînera des changements potentiellement importants dans votre backlog. Ainsi, un backlog produit plus court et moins détaillé est logique au début du cycle de lancement, explique Pichler. 

Bill Wake, un consultant Agile qui travaille maintenant avec Industrial Logic Inc, a mis au point un modèle mnémotechnique largement utilisé pour les caractéristiques d’un bon récit utilisateur, l’acronyme INVEST :

I - Indépendant - Les récits ne doivent pas se chevaucher et peuvent idéalement être mis en œuvre dans n’importe quel ordre.
N - Négociable - Le récit saisit l’essentiel, mais pas les détails, qui sont convenus par les participants.
V - Valorisé - Le récit offre une valeur claire au client. 
E - Estimable - Vous êtes en mesure d’évaluer l’effort nécessaire. Il peut s’agir d’une estimation du temps ou de ce qu’on appelle des story points, une unité de mesure arbitraire qui évalue la complexité relative (comme XS, S, M, L, XL ou 1, 2, 4, 8, 16). 
S - Succinct - « Les bonnes histoires ont tendance à être courts », commente Wake. Cela signifie que l’histoire doit être réalisée en (au plus) quelques semaines de travail de 40 heures d’une personne dédiée, ou divisée entre les membres de l’équipe. 
T - Testable - Le récit utilisateur doit être mesurable ou exploitable d’une certaine manière, selon Ulf Eriksson, fondateur et product owner de la plateforme de test informatique ReQtest.

Cohn souligne que tous les éléments du backlog ne doivent pas être un récit utilisateur. « Je rencontre des équipes qui pensent que chaque élément du backlog produit doit être un récit utilisateur. Les récits utilisateurs sont excellents, quand ils correspondent à des utilisateurs. Mais certaines choses qui appartiennent à un backlog produit ne sont pas nécessairement directement destinées aux utilisateurs. Ces éléments n’ont pas besoin d’être écrits en tant que récits utilisateurs ». 

Cela inclut le travail sur le backend ou d’autres tâches éloignées des utilisateurs. Cohn recommande de décrire ces tâches à l’aide de la syntaxe de développement axé sur les fonctionnalités (FDD) (verbe + résultat + objet, c’est-à-dire « Valider le mot de passe d’un utilisateur »).
Les quatre types d’éléments couramment trouvés dans les backlogs Scrum sont les fonctionnalités, les bugs, le travail technique et l’acquisition de connaissances. Les fonctionnalités sont souvent exprimées sous forme de récits utilisateurs, mais pas les autres éléments.

Si vous commencez à peine, ne vous inquiétez pas : vous n’avez pas besoin de commencer votre projet avec un backlog produit parfait. Commencez par réfléchir aux tâches nécessaires : cela vous donnera suffisamment d’informations pour votre premier sprint. Ensuite, vous pouvez développer votre backlog produit à mesure que vous en apprendrez plus sur le produit, les besoins des utilisateurs et les retours.

« Mon conseil principal en ce qui concerne les backlogs produit serait de rester simple. Il ne s’agit que d’une structure de répartition du produit commandé », explique Laurens Bonnema, consultant Agile chez Xebia aux Pays-Bas.

C.J. Boat, un chef d’équipe Agile pour le marché de l’assurance Ensurem, confirme. « Ayez des attentes raisonnables ! Si vous laissez votre carnet de commandes devenir trop important, ou si vous n’organisez pas correctement votre travail, le backlog et les sprints peuvent devenir si lourds qu’ils s’effondreront », explique-t-il.

Une fois que vous avez ajouté les tâches, il est temps de mettre en ordre le backlog produit. Placez le travail plus important au-dessus du travail moins important. Vous pouvez le faire en fonction de votre estimation de priorité, en prenant des décisions au fur et à mesure sur la manière de classer les éléments ayant la même priorité.

« Lorsque vous ajoutez des tâches à votre backlog, attribuez-leur une note de priorité initiale », conseille Kevin Lonergan, consultant principal en gestion de projet chez PMIS Consulting en Grande-Bretagne. « Trois niveaux simples de priorité suffisent : 1 - essentiel pour atteindre les objectifs de l’entreprise, 2 - utile mais pas critique, 3 - serait un bonus si ces éléments sont terminés. »

Certains praticiens disent qu’une meilleure méthode consiste à classer la liste selon d’autres critères tels que le risque, le retour sur investissement, le coût-bénéfice, un modèle de type MoSCoW (doit avoir, aurait dû, aurait pu, n’aura pas), l’impact d’un récit sur l’autre, le temps estimé pour la mise en œuvre, ou les interdépendances.

Bonnema, chez Xebia, préfère la méthode Weighted Shortest Job First (WSJF), décrite par Donald Reinertsen dans « The Principles of Product Development Flow » et développée par Dean Leffingwell, créateur du Scaled Agile Framework. Il s’agit d’une formule qui permet de hiérarchiser le backlog produit en fonction de la durée des tâches et d’une estimation du coût du retard. « Je n’ai pas de meilleur moyen de hiérarchiser correctement les backlogs à tous les niveaux que le WSJF », déclare Bonnema. Les tâches restent dans le backlog oroduit jusqu’à ce qu’elles soient terminées ou jusqu’à ce que le Product Owner décide qu’elles ne sont plus nécessaires. 

Pour déterminer quand un récit utilisateur est terminé et peut être supprimé du backlog, les équipes doivent développer une « définition du terminé » standardisée. Il s’agit des critères d’acceptation d’une fonction qui garantit que tous les membres de l’équipe savent ce que l’on attend du travail qu’ils livrent. Kelly Waters, auteure de All About Agile, pense que « terminé » devrait signifier livrable. Jeff Sutherland, PDG de Scrum Inc., utilise l’expression Agile populaire «terminé terminé», ce qui signifie qu’à la fin du sprint, le codage est fait et que les tests logiciels sont finis au niveau des fonctionnalités, sans aucun bug. Lorsqu'il correspond à la définition de « terminé » de votre équipe, un élément peut être déplacé du backlog produit vers la colonne des réalisations.

Maintenant que vous savez ce qu’est un backlog produit et ce qui en fait ou non partie, voici votre checklist pour créer votre premier backlog produit :

1. Le Product Owner est en charge du backlog produit. Si c’est vous, vous êtes en charge de créer le backlog produit, mais vous n’avez pas besoin d’être la seule personne impliquée. Les membres de l’équipe Scrum et d’autres parties prenantes peuvent participer.
2. Rappelez-vous que le backlog produit est la liste complète de tous les récits utilisateurs et autres éléments de travail pour le produit.
3. Pensez à chaque tâche que vous pouvez et notez-la. Soyez aussi précis que possible et demandez des commentaires de toutes les parties pertinentes de votre organisation et des retours des clients.
4. Créez des récits du point de vue de l’utilisateur en indiquant une action et une raison. (En tant que _, je veux _, pour_.) Pensez à tous les utilisateurs différents. Écrivez-les sur des fiches ou utilisez un outil en ligne. Appliquez des balises pour que la version prévue soit claire.
5. Incluez des corrections de bugs, l’acquisition de connaissances et le travail technique.
6. En tant que Product Owner, vous seul évaluez l’importance de chaque élément pour l’organisation, allant de très élevé à très faible, ou en utilisant une autre méthode. Vous pouvez interroger les utilisateurs pour disposer d’une base solide pour ces décisions. 
7. Pour chaque élément de travail, fournissez également une estimation de l’effort qu’il implique.
8. Classez le backlog produit. 
9. Le travail que l’équipe s’engage à accomplir dans un sprint est le backlog Sprint, qui est distinct du backlog produit. Le backlog Sprint ne change pas pendant le sprint. Les éléments sont considérés comme terminés et supprimés du backlog Sprint et du produit lorsqu’ils sont « terminés ».
10. Lorsque de nouveaux travaux arrivent, ajoutez-les au backlog produit dans la bonne position. Lorsque vous recueillez de nouvelles informations, comme des commentaires, vous pouvez supprimer ou réorganiser des éléments. 

Une fois que vous avez terminé, vous devriez vous retrouver avec quelque chose comme ceci :

À ce stade, les félicitations sont de mise si vous avez réussi à rédiger votre premier backlog produit et à faire travailler votre équipe Scrum sur un lot de récit utilisateurs précieux au cours d’un sprint. Mais ce n’est toujours pas le moment de se détendre. 

Une fois créé, le backlog produit doit être maintenu et mis à jour en permanence. Ce processus, également connu sous le nom d'affinement ou de nettoyage du backlog produit, permet d'actualiser votre backlog en fonction des informations du marché, des utilisateurs, de l’équipe produit et de la direction de votre organisation. En nettoyant bien votre backlog, vous vous assurez que l’équipe de développement met toujours ses efforts au bon endroit, que vous êtes prêt pour le prochain Sprint, que vous utilisez bien vos ressources et que vous livrez le meilleur produit possible à votre client. 

Un moyen facile de se souvenir de l’objectif du processus d’affinement du backlog produit est l’acronyme DEEP. Votre objectif est de vous assurer que votre backlog produit est toujours DEEP (profond) :

D - Détaillé de façon appropriée afin que les éléments en haut de la liste aient plus de détails que ceux en bas. 
E - Estimé - Chaque élément du backlog produit, ou du moins ceux impliqués dans la prochaine version, doit être estimé en fonction de l’histoire ou de l’heure. À mesure que votre équipe obtient plus de travail, sa vitesse (la vitesse à laquelle elle termine les éléments du backlog du produit) deviendra plus claire et facilitera l’estimation.
E- Émergent - Cela signifie que le backlog produit est adapté aux nouveaux éléments ou informations qui apparaissent.
P- Priorisé - Tous les éléments du backlog produit sont classés en plaçant les plus importants en haut. 

Même si vous faites tout votre possible pour que votre backlog produit fonctionne correctement, des problèmes peuvent survenir. Les experts Agile qui ont travaillé avec de nombreuses équipes et sur divers projets ont des conseils pour dépanner, et éviter les problèmes.

Le coach Agile Kroll explique que les problèmes les plus courants qu’il voit proviennent d’un manque de participation de ceux qui financent les projets, qui doivent être impliqués au quotidien, et d’une tendance à faire pression sur l’équipe pour atteindre des objectifs de temps qui ne sont pas déterminés par la capacité réelle de l’équipe. La solution est que les managers passent d’un état d’esprit de projet « planifié vs. réel » traditionnel à une approche Agile. 

Jonathan Roger, chef de projet et Scrum Master pour AndPlus, recommande de garder un « icebox » (glacière) au bas du backlog produit pour les idées non prioritaires et non nettoyées. « Les Product Owners peuvent suivre les fonctionnalités souhaitées à long terme sans pression pour les traiter dans l'ordre de priorité, et les équipes peuvent ajouter leurs idées potentielles pour que le Product Owner les revoie. C'est également un bon point de départ pour les demandes de fonctionnalités des clients ou des parties prenantes. » 

Lonergan, de PMIS Consulting, recommande de choisir soigneusement le Product Owner comme clé du succès. « Une personne doit assumer le rôle de Product Owner, pas un comité », souligne-t-il. « Elle est propriétaire du backlog produit. Assurez-vous que le Product Owner dirige le développement du backlog. »

« L'erreur n°1 est sans aucun doute de désigner la mauvaise personne comme Product Owner en raison du manque d’autorité, de connaissances du domaine, de temps, etc. », ajoute Lonergan. 

De la simple gestion de tâches et de projets à la gestion complexe de ressources et de portefeuilles, Smartsheet vous aide à améliorer la collaboration et à accélérer le travail. Vous avez ainsi les moyens d'accomplir plus de travail. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports de synthèse sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.