Pensez d’abord à la valeur et aux coûts, puis tenez ensuite compte d’autres facteurs qui affectent la priorité d’un élément du product backlog : L’apprentissage, le risque et les dépendances.

5 Key Factors for Effective Product Backlog Prioritization par Mike Cohn

https://www.mountaingoatsoftware.com/blog/5-key-factors-for-effective-product-backlog-prioritization

Les arriérés de produits (product backlog) contiennent toutes les fonctionnalités connues qui finiront par se retrouver dans le produit. Qu’il s’agisse d’histoires utilisateur (user stories), d’histoires métier (job stories) ou d’une simple phrase ou deux, il est essentiel d’ordonner le backlog afin que les équipes construisent toujours les fonctionnalités les plus prioritaires. En plus de créer les bonnes fonctionnalités, il est important de les construire dans le bon ordre. Voici les 5 éléments clés à prendre en compte lorsque vous réfléchissez à la façon de hiérarchiser le backlog produit.

Facteur #1 : La Valeur

Commençons par le gros problème : la valeur. Et bien qu’il soit évident de considérer la valeur d’une fonctionnalité, « valeur » est un terme nébuleux.

La valeur est une mesure de l’utilité ou de l’impact sur un public particulier. La plupart des travaux qu’une équipe de développement agile entreprendra seront précieux pour les utilisateurs. Mais d’autres travaux peuvent être précieux seulement pour l’équipe elle-même. D’autres travaux seulement pour certains utilisateurs, parties prenantes et membres de l’équipe.

Par exemple, considérez la refactorisation ou réusinage de code ( le refactoring ) : Améliorer la structure mais pas le comportement du code. Parce qu’elle rend le code plus facile à maintenir ou à modifier, la refactorisation est d’une grande valeur pour les développeurs.

Le coût de la refactorisation est généralement justifié, cependant, car il profite également aux utilisateurs. Si le code est plus facile à maintenir, les utilisateurs devraient rencontrer moins de bogues. De même, un code amélioré signifie que les utilisateurs devraient recevoir un peu plus rapidement les nouvelles fonctionnalités dans ce domaine du produit. (Pour plus de façons de justifier la priorisation de la refactorisation, voir « 4 Ways to Persuade a Product Owner to Prioritize Refactoring. »)

Lorsque l’on réfléchit à la valeur d’une fonctionnalité, il peut être important de réfléchir à la façon dont la valeur d’une fonctionnalité se dégrade au fil du temps. Une fonctionnalité peut être très précieuse aujourd’hui, mais beaucoup moins précieuse plus tard.

L’un des exemples les plus forts que j’ai vus de cela est survenu lorsque je travaillais avec une équipe créant des logiciels pour soutenir les ligues de sports. Certaines fonctionnalités devaient être présentes le jour du repêchage, lorsque tous les joueurs sélectionnaient leur équipe. Si la fonctionnalité n’était pas disponible le jour du repêchage, les joueurs formeraient probablement leur ligue sur une autre plateforme. Le coût du retard dans ce cas était énorme.

Facteur #2 : Le Coût

La deuxième chose à considérer lors de l’établissement des priorités est le coût. Le coût le plus important est généralement l’effort de l’équipe produit pour développer une fonctionnalité. La plupart des équipes utilisent des story points pour estimer l’effort des éléments du backlog produit. D’autres estiment cet effort en jours-personnes, en temps idéal ou en d’autres unités similaires.

Dans certains cas, il peut y avoir des coûts supplémentaires qui doivent être pris en compte. Une considération commune actuelle ? Le coût permanent de la fourniture de fonctionnalités qui reposent sur divers produits d’IA. Ces produits incluent souvent de petits frais à l’utilisation, mais ceux-ci peuvent certainement s’additionner à grande échelle.

Quelle que soit l’unité dans laquelle une équipe estime les éléments de son backlog produit, le coût de développement et de support d’une fonctionnalité doit être pris en compte dans la priorité d’un élément. Par exemple, un élément qu’une équipe estime à 5 doit être prioritaire par rapport à une fonctionnalité estimée à 20 si toutes choses sont égales par ailleurs. Cela est vrai quelle que soit l’unité d’estimation utilisée par l’équipe.

Facteur #3 : L’Apprentissage

Un troisième facteur à prendre en compte lors de l’établissement des priorités est le suivant : Qu’est-ce qu’une équipe apprendra en effectuant un élément particulier du backlog de produit ? Si vous apprenez quelque chose en développant un élément du backlog, vous voudrez probablement développer cet élément tôt afin d’avoir le temps d’agir sur ce que vous avez appris.

Si vous apprenez quelque chose trop tard, vous n’aurez pas le temps de profiter des nouvelles connaissances.

L’apprentissage peut prendre deux formes. Il peut s’agir du produit ou du projet.

Apprendre à connaître le produit

L’apprentissage du produit se produit lorsque l’équipe développe une fonctionnalité et reçoit des commentaires à son sujet.

Si les utilisateurs aiment la fonctionnalité, privilégiez l’amélioration de la fonctionnalité ou la création d’autres choses similaires. Si les utilisateurs ne l’aiment pas, envisagez de supprimer la fonctionnalité ou de réduire la priorité des fonctionnalités associées.

En savoir plus sur le projet

L’apprentissage du projet fait référence aux connaissances que les membres de l’équipe acquièrent sur la façon de développer le produit ou la solution. Par exemple, supposons qu’une équipe ait l’intention de construire une partie d’un produit à l’aide d’une technologie que ses membres n’ont jamais utilisée auparavant.

Lorsque les membres de l’équipe développent le premier élément du backlog de produit à l’aide de cette nouvelle technologie, ils apprennent des choses à ce sujet, telles que :

• La technologie fonctionne-t-elle comme promis ?
• Les estimations relatives à l’utilisation de la nouvelle technologie devraient-elles être révisées ?
• La technologie peut-elle être utilisée dans d’autres parties du produit ou du projet ?

N’oubliez pas le fait d’apprendre lorsque vous pensez à la hiérarchisation agile du backlog. Le potentiel d’une fonctionnalité à enseigner à l’équipe et à ses parties prenantes quelque chose sur les besoins des utilisateurs ou les réalités du projet peut être une raison suffisante pour en faire une priorité absolue.

Facteur #4 : Le Risque

Le quatrième facteur à prendre en compte lors de l’établissement des priorités est le risque inhérent à l’élaboration de l’élément du backlog produit. Si quelque chose est risqué et que vous devez le faire, faites-le tôt. Vous voulez savoir si ce risque va se matérialiser.

D’un autre côté, si une fonctionnalité est risquée et que vous n’avez peut-être pas besoin de la développer, retardez le travail dessus jusqu’à ce qu’il devienne clair que vous devez la faire.

Facteur #5 : Les Dépendances

Le dernier facteur que vous devez prendre en compte lors de la hiérarchisation des priorités est les dépendances entre les éléments du backlog produit. Certains items ne sont peut-être pas prioritaires en soi, mais ils sont nécessaires à la livraison d’autres articles. Lorsque c’est le cas, l’élément d’activation mais moins prioritaire doit être déplacé plus haut dans le backlog afin d’être terminé avant que l’élément n’en dépende.

À titre d’exemple, considérez un camp d’été où j’ai aidé à utiliser Scrum. Parmi les éléments de l’arriéré de produits, il y avait « peindre tous les canots ». C’était une priorité élevée, car ils voulaient montrer des photos de canoës brillants et nouvellement peints dans leur marketing.

Mais peindre les canots dépendait d’un autre élément de l’arriéré de produit : Poncer et réparer les canoës qui en avaient besoin.

Techniquement, la réparation des canoës n’avait pas besoin d’être effectuée avant un jour ou deux avant l’ouverture du camp d’été, mais cet élément était prioritaire dans le backlog des produits car les photos marketing des canoës devaient être prises bien avant cela.

Techniques formelles de hiérarchisation de l’arriéré

Il existe de nombreux cadres de travail pour la hiérarchisation afin de vous aider à comparer ces facteurs les uns par rapport aux autres de manière plus granulaire, notamment le modèle de Kano, le modèle de notation RICE et la pondération relative. Même avec ces méthodes formelles, lors de la création d’une feuille de route de produit, les facteurs que j’ai énumérés ici doivent être pris en compte, même s’ils ne font pas explicitement partie de ces modèles.

Cependant, vous pouvez obtenir un classement des éléments du backlog de produit en réfléchissant simplement à ces cinq facteurs. Lorsque vous faites cela, je ne vous recommande pas de les combiner avec une formule sophistiquée.

La valeur d’une fonctionnalité et son coût, c’est-à-dire nos premier et deuxième facteurs, sont les plus importants. Établissez donc d’abord les priorités en fonction du coût et de la valeur, en utilisant les trois autres facteurs (apprentissage, risque et dépendances) pour ajuster les priorités et résoudre les conflits.

Par exemple, supposons qu’un propriétaire ou un chef de produit ait hiérarchisé un élément de sorte qu’il ne soit pas terminé avant trois ou quatre autres itérations en fonction de sa valeur et de son risque. À ce stade, tenez compte de l’apprentissage, des risques et des dépendances. Avancez l’élément d’une itération ou deux si l’un de ces facteurs est significatif.

5 facteurs pour une hiérarchisation efficace des priorités

Dans les équipes agiles et Scrum,  les product owners sont chargés de tenir le backlog produit ordonné par priorité. Une façon simple d’aborder cela, sans utiliser de techniques formelles de hiérarchisation du backlog de produit, est de garder cinq facteurs à l’esprit. Pensez d’abord à la valeur et au coût. Tenez ensuite compte d’autres facteurs qui affectent la priorité d’un élément du backlog produit : L’apprentissage, le risque et les dépendances.

Lorsque vous le faites dans le cadre de vos efforts de planification agile , vos équipes ne se contenteront pas de construire les bonnes choses, elles les construiront dans le bon ordre.