17 erreurs à ne surtout pas commettre avec le product backlog

Vous serez d'accord avec moi pour dire que le backlog produit est l'élément le plus important en gestion de projet agile. Sans lui, pas de produit !

Vous pouvez toujours essayer d'avancer avec la méthode "à l'arrache" (au jour le jour, sans rien noter et pilotage au doigt mouillé) , mais vous allez vous casser les dents(et les rotules).

Vous pouvez toujours essayer le cycle en V ou la méthode Waterfall, mais ça veut dire que le périmètre du projet est figé. Autrement dit, quand le client aura une évolution à intégrer au produit ce ne sera pas possible. Alors que c'est un peu le but du mode produit...

Bref, vous ne pouvez pas composer sans un product backlog de qualité.

Et ça tombe bien car dans cet article, je vous expose les pièges les plus courants à éviter.

17 erreurs à éviter avec votre product backlog

Je vais assumer dans la suite de l'article que vous savez déjà ce qu'est un product backlog, à quoi il sert et qui en est responsable. Si ce n'est pas le cas, je vous invite vivement à lire d'abord cet article avant de continuer celui-ci.

1 ) Ne pas adapter le backlog en fonction du feedback

Si le product owner hiérarchise le backlog au tout début du projet mais qu'il ne l'adapte pas en fonction du feedback de l'équipe de développement et des parties prenantes, alors vous avez un problème sur les bras à résoudre rapidement.

Cela veut dire que le product owner se la joue "rogue" : il n'en fait qu'à sa tête, et agit seul sans se préoccuper du reste de l'équipe Scrum. Et ça, pour le produit et le projet c'est très mauvais.

La gestion de projet agile est construite autour de la notion de collaboration.

Bien que le product owner soit responsable de la création et du maintien du product backlog, il se doit d'échanger avec tout le monde et de tenir compte du feedback afin d'améliorer les items du backlog.

Des éléments de meilleure qualité = un incrément de qualité = des utilisateurs satisfaits = un produit "top moumoute".

2 ) Limiter les éléments du backlog à ce qui concerne directement le client

Limiter les éléments du backlog au "front-end", directement visible par le client et les utilisateurs est une mauvaise idée. 

Pour avoir un bon produit, fiable, robuste, et de qualité, pas le choix il faut aussi traiter des éléments invisibles des utilisateurs.

Par exemple, c'est bien beau de faire une interface web aux petits oignons, mais tout le contenu derrière doit être stocké dans une base de données. Ce n'est pas du tout visible pour le client, mais pourtant il faut le faire.

C'est pour cela que le product backlog ne contient pas que des user stories (les récits utilisateurs) décrivant les fonctionnalités souhaitées par les utilisateurs du produit.

Un product backlog, ça peut aussi contenir des items techniques à réaliser, des bugs à corriger, des spikes (hypothèses à vérifier), etc...

3 ) Ne pas rendre le product backlog public

"Chez nous, le backlog est conservé sous forme de document stocké en local et peu partagé, ce qui empêche les parties concernées de se tenir informées".

En voilà une mauvaise idée...

Le product backlog doit au contraire être public. Il doit pouvoir être consultable à tout moment par l'équipe de développement, le product owner, le scrum master mais aussi les parties prenantes.

Cela permet d'assurer de la transparence et donc de générer la confiance nécessaire pour mener à bien le projet agile.

ça favorise également la collaboration et la co-construction entre les membres de la Scrum team et les parties prenantes.

4 ) Avoir un product backlog conséquent (200 items ou plus)

Un backlog volumineux est une galère sans nom à gérer, détailler, affiner et ordonnancer au quotidien. 

Le product owner a donc tout intérêt a le garder aussi petit que possible, déjà pour se faciliter la vie, mais aussi pour éviter de devoir jeter du travail, ou refaire plusieurs fois la même chose.

On recommande généralement de garder le product backlog entre 40 et 60 items.

5 ) Traiter le backlog comme un cahier des charges fixe

Le cahier des charges n'est PAS un product backlog, et inversement. 

Dans un cahier des charges, le client décrit de façon exhaustive tous ses besoins avant de lancer le projet. Le budget est donc construit autour d'un nombre précis de fonctionnalités à développer.

Et si le client a oublié d'y insérer un besoin, dommage pour lui : c'est trop tard. Le périmètre d'un cahier des charges est figé.

Le product backlog, quant à lui, contient la liste des éléments que l'on souhaiterait réaliser dans un proche futur afin d'atteindre un product goal. Il est en constante évolution, et est ouvert au changement.

6 ) Gérer plusieurs backlogs pour un seul produit

Le guide scrum nous dit que le product backlog contient les éléments nécessaires à l'atteinte du product goal. 

Chaque produit ayant un product goal bien défini, il est donc logique qu'un produit ne soit associé qu'à un seul product backlog.

Sans cela, ce serait la porte ouverte à tous les abus, et notamment aux méthodologies de gestion de projet "à l'arrache".

7 ) Gérer un backlog par équipe Scrum pour un même produit

Comme précédemment, le scrum guide est on ne peut plus clair sur le sujet : "le product backlog est unique". Il n'en existe qu'un et qu'un seul par produit.

S'il est nécessaire d'avoir plusieurs équipes Scrum afin d'atteindre le product goal, alors le product owner et le product goal doivent être similaires et partagés entre toutes les équipes.

8 ) Confondre le product backlog et le sprint backlog

Le product backlog contient tous les éléments nécessaires de traiter afin d'atteindre un objectif produit. Il est sous la responsabilité du product owner, et est présent tant que le développement du produit n'est pas terminé.

Le sprint backlog est un sous-ensemble du product backlog, et en contient que les éléments suffisament détaillés pour pouvoir être développés lors du sprint actuel et ainsi atteindre l'objectif de sprint. 

Ce backlog est de la responsabilité de l'équipe de développement, et a une durée de vie de 1 sprint.

9 ) Attendre plusieurs semaines ou mois avant de démarrer le premier sprint

En mode produit (et en agile), on ne souhaite qu'une seule chose : se confronter le plus rapidement possible aux utilisateurs afin de valider les hypothèses et d'obtenir les premiers feedbacks.

Comment faire ça du coup lorsqu'on passe plusieurs mois sur un product backlog, afin d'être sûr de "penser à tout" ? C'est une grave erreur !

En procédant ainsi, vous prenez le risque de devoir refaire une bonne partie du travail, ou de devoir tout jeter à la poubelle et recommencer. On a vu mieux en matière d'efficacité.

A partir du moment où le product goal est défini, le product owner peut travailler avec l'équipe de développement afin d'identifier les premiers éléments.

Encore mieux, servez-vous du sprint planning du premier sprint pour faire ce travail et lancer la machine.

10 ) Ne pas faire vivre le backlog au quotidien

Un backlog, c'est quelque chose de vivant, de dynamique, d'évolutif. 

Les priorités changent de jour en jour, les éléments en haut de la pile sont de plus en plus affinés et détaillés, de nouveaux items se rajoutent au fur et à mesure des itérations et des découvertes de l'équipe Scrum, les items obsolètes sont supprimés sans regret.

Un backlog n'est pas quelque chose de figé. Ne le considérez pas comme un cahier des charges exhaustif rédigé par le client, car ce n'est pas du tout ça.

11 ) Ne pas organiser de session de toilettage

Laisser moisir son product backlog est rarement une bonne idée. On finit par se retrouver avec une flopée d'items qui n'apportent pas ou peu de valeur et ne servent à rien.

Et à un moment, il faut bien faire quelque chose.

Les sessions de toilettage du backlog, ou grooming session, permettent de garder le backlog à jour et de maintenir sa pertinence.

Ces sessions permettent d'éliminer le superflu ou les éléments obsolètes, afin de se concentrer surce qui apporte vraiment de la valeur.

12 ) Ne pas établir correctement les priorités

Si vous ne priorisez pas correctement les éléments du product backlog, cela aura plusieurs conséquences fâcheuses :

• Vous perdrez du temps.
  Comme vous n'avez pas choisi l'ordre le plus logique, vous mettrez plus de temps à atteindre le product goal, ce qui représente un investissement supplémentaire.
  
• Vous ne fournirez pas le meilleur incrément possible au client.
  Vous ne maximisez pas la valeur apportée au client, puisque les items qui font leur chemin dans le sprint backlog ne sont pas les plus prioritaires.
  
• Vous augmenterez les chances de friction.
  Votre client et les parties prenantes peuvent en pas être satisfait par le travail fourni. Dans les cas les plus graves, l'équipe Scrum pourrait même perdre la confiance du client.
  
• Le risque que le projet soit un échec augmente.
  Si l'incrément produit ne répond pas aux attentes du client, il peut très bien décider d'arrêter le projet où il en est. Ce sera un échec retentissant.
  

13 ) Ne pas impliquer l'équipe de développement ou les parties prenantes

Si le product owner décide seul du product backlog et impose à l'équipe de développement le travail à réaliser, vous avez deux problèmes :

1. Il ne représente pas les parties prenantes.
   Or, le scrum guide est catégorique sur le sujet, le product owner doit les représenter au sein de l'équipe Scrum.
   
2. Vous ne faites pas de l'agile.
   Vous reproduisez un schéma de gestion de projet classique déguisé en agile. C'est un waterfall qui ne dit pas son nom.
   

En procédant ainsi, vous n'arriverez pas à déterminer comment apporter le plus de valeur au client. Et vous vous retrouverez avec une équipe de développement absolument pas motivée pour s'investir dans le produit.

Bref, c'est un boulevard vers l'échec.

14 ) Autoriser n'importe qui à modifier le product backlog

La gestion du product backlog est de la responsabilité du product owner à 100%. Lui seul doit pouvoir le modifier.

D'ailleurs, le guide Scrum nous dit que "Le product owner est redevable de la gestion efficace du product backlog".

Lorsque des besoins émergent ou sont découverts, les parties prenantes et l'équipe de développement doit en informer le product owner. C'est ce travail de collaboration qui permet ensuite au PO (product owner) de tenir son backlog à jour et de le prioriser selon la valeur.

A ce sujet, le guide Scrum nous précise bien que :

Clair, net, précis, sans équivoque.

15 ) Dévier du product goal

Tous les éléments qui sont inscrits dans le product backlog doivent permettre d'atteindre d'une manière ou d'une autre le product goal. Si ce n'est pas le cas, ils n'ont rien à faire ici.

C'est aussi pour ça que l'on recommande de garder un backlog produit le plus "light" possible, idéalement entre 40 et 60 items.

De toute façon, ce backlog n'est pas exhaustif : il va vivre dans le temps. Certains éléments vont apparaître, d'autres disparaître.

Lorsque vous êtes tenté d'ajouter un item au backlog, demandez-vous toujours si celui-ci permet vraiment d'atteindre l'objectif de produit.

16 ) Trop détailler les éléments du product backlog

Ce n'est pas parce que le product backlog contient 60 éléments qu'il est nécessaire de tous les détailler dans les moindres détails. 

C'est normal d'avoir des éléments détaillés dans le backlog (généralement ceux qui sont priorisés), et d'en avoir d'autres qui sont encore flous (les moins prioritaires).

Trop détailler à l'avance les items du product backlog, c'est prendre le risque de devoir refaire le travail ou pire de devoir le jeter. C'est du gâchis de temps qui nous fait perdre en efficacité.

La bonne pratique est donc de ne détailler que les éléments prioritaires, afin qu'ils soient compréhensibles par les parties prenantes et l'équipe de développement.

Vous pouvez ensuite vous baser sur la definition of ready afin de garantir la tenue des bonnes pratiques avant de basculer les user stories en statut "développement" dans le sprint backlog.

17 ) Faire tout ce qui est décrit dans le product backlog

Le product backlog n'est pas une liste de tâches exhaustive. Ce n'est pas une checklist à cocher à 100% pour déclarer le projet terminé. Ce n'est pas non plus une liste de courses du client.

Le product backlog est une liste d'options que l'on se réserve le droit de faire dans le futur, sans aucune obligation.

Il est dynamique, évolutif et émergent, il change donc au quotidien afin de refléter ce qu'il est nécessaire de faire à un instant t afin d'atteindre le product goal.

L'équipe Scrum doit se concentrer sur ce qui apporte le plus de valeur, c'est à dire les éléments les plus importants du product backlog (ceux en haut de la pile).

Ainsi, étant donné qu'un projet agile peut s'arrêter n'importe quand, on s'assure de toujours délivrer le maximum de valeur possible au client.