Eléments du Backlog Produit

Auteur : Jim Coplien
Source : Product Backlog Items (Published Patterns)

---

Traducteur : Fabrice Aimetti
Date : 15/08/2011

---

Traduction :

... vous construisez un BACKLOG PRODUIT à partir d'éléments qui portent le métier.

Vous souhaitez mieux organiser le travail pour optimiser le ROI (Retour sur Investissement) de l'entreprise. Scrum se concentre énormément sur la façon d'organiser le travail, et il est évident que "bien faire les choses" contribue à l'obtention d'un bon ROI. Cependant, on peut relier le ROI de façon plus étroite aux parties prenantes, autrement dit "faire les bonnes choses".

Plus largement, le ROI résulte de la valeur ajoutée livrée aux parties prenantes. Une entreprise a de nombreuses parties prenantes : clients, utilisateurs finaux, actionnaires, concepteurs, architectes, développeurs et testeurs, et chacun contribue à cette perception globale de la valeur.

Un système idéal augmente la valeur métier pour toutes les parties prenantes, plutôt que pour un seul au détriment des autres. Même si chacun peut donner quelque chose (temps, argent, travail), nous voulons atteindre un paradoxe selon lequel chacun reçoit plus que ce qu'il a donné, ou tout au moins, en étant plus cynique, que chacun reçoit autant qu'il a donné.

Par conséquent : créez des Éléments du Backlog Produit(PBI) pour concrétiser les incréments produit qui ont une valeur métier pertinente pour les parties prenantes. La partie prenante la plus courante est le marché, ou son représentant, le Product Owner. Cependant, un élément du Backlog Produit peut aussi décrire le travail qui réduit les coûts pour l'entreprise ou qui réduit les efforts pour l'équipe de développement, c'est même un outil qui aidera l'équipe Product Owner à mieux faire son travail. Un élément du Backlog Produit est quelque chose qui a une valeur potentielle pour une partie prenante.

Assurez-vous que les éléments du Backlog Produit reflètent toutes les dépendances entre les tâches de développement nécessaires pour les réaliser.

Les éléments du Backlog Produit ont tendance à être centrés sur les parties prenantes, plutôt que sur l'équipe. L'équipe doit gérer ses propres éléments de travail sous la forme de Tâches ; sans ingérence ou conseils de la part du PRODUCT OWNER, qui a mieux à faire. Ainsi, par exemple, le refactoring et la correction de bugs ne seront probablement pas des éléments du Backlog Produit pour un produit logiciel. Parfois, cependant, ces éléments occuperont une place tellement importante qu'ils menaceront l'entreprise sur le long terme. Dans une situation extrême, le PRODUCT OWNER pourra inclure des bugs, une partie de la réduction de la dette technique - et d'autres choses traditionnellement considérées comme internes et n'apportant pas de valeur métier directe - parce qu'elles sont devenues assez sérieuses pour mériter la surveillance du Métier. Si le Product Owner passe beaucoup de temps à traiter de telles questions, celles-ci devront être considérées comme des obstacles. Voir aussi Illigitimus Non Interruptus.

Normalement, les éléments du Backlog Produit ne devraient pas être des éléments de travail ou tâches : dans ce cas, on confond la valeur livrée, avec le mécanisme utilisé pour créer cette valeur. Ce type de confusion peut entraîner l'entreprise à perdre sa concentration, théoriquement dédiée au marché.

Vous pouvez commander des éléments du Backlog Produit sur la base du ROI. Vous pouvez le faire soit sur la base du ROI individuel des éléments du Backlog Produit relativement indépendants (LA VALEUR MÉTIER LA PLUS GRANDE D'ABORD) ou sur la base du ROI global sur le long terme.