Le projet est maintenant bien cadré, les exigences sont réunies et tout le monde se prépare pour commencer la course. Mais un rapide coup d’œil à la longue liste de user stories vous laisse pressentir qu’il sera impossible de toutes les traiter dans le délai imparti. Il est donc essentiel de passer à la prochaine étape : la priorisation du Backlog.
Prioriser : une clé du succès
Pourquoi prioriser ? L’objectif est de fournir une valeur « business » maximale le plus tôt possible. Le chemin le plus court vers la mise en production consiste à développer le Produit Minimum Viable (MVP), nécessitant alors de revoir et prioriser le Backlog.
Comment prioriser ?
Alors que le client et les parties prenantes sont en mesure d’estimer valeur apportée par chaque fonctionnalité, seuls les développeurs et les experts peuvent estimer la charge de travail et les risques techniques associés. Pour le succès du projet, la prise en compte de ces deux aspects est primordial. La priorisation requiert alors une approche collaborative.
Jetons un coup d’œil à quelques techniques de priorisation du backlog ayant fait leur preuve en matière d’assistance à maitrise d’ouvrage et de développement logiciel.
Analyse MoSCoW
Cette technique tire son nom des initiales de chaque catégorie proposée – en anglais : les « Must-have » ou les « incontournables », les « Should-have » ou les « essentiels », les « Could-have » ou les « conforts » et enfin les « Won’t-have » ou les « Pas maintenant ».
La répartition des fonctionnalités dans chacune des quatre catégories est proposée comme suit :
« Must-have » ou les « Incontournables » – c’est le minimum absolu à livrer pour constituer le MVP. Sans eux, le produit ne pourra pas délivrer, selon les cas, la valeur, la sécurité ou la qualité attendue.
« Should-have » ou les « Essentiels » – ce sont les fonctionnalités pas nécessairement vitales, mais importantes. Celles-ci sont largement souhaitables en raison de leur valeur pour les parties prenantes ou pour les utilisateurs finaux.
« Could-have » ou les « Conforts » – moins d’impact sur le produit final s’il est laissé de côté.
« won’t have » ou les « Pas maintenant » –
– les fonctionnalités pas prévues pour maintenant et considérées dans l’immédiat comme un luxe, mais il est toujours important de les documenter au cas où elles pourraient être réintroduites plus tard.
Le succès de cette technique dépend de la distinction claire des quatre catégories ci-dessus et du consentement mutuel sur le statut attribué à chaque fonctionnalité.
Par ailleurs, il est conseillé de conserver un rapport de 3 : 1 : 1 entre les Must-have, Should-have et Could-have afin d’équilibrer et de pouvoir gérer tout imprévu.
La méthode MoSCoW, si elle est correctement appliquée, offre au client et à l’équipe de développement une bonne perspective de réussite d’un projet.
Le test des cent euros
Le test des cent Euros consiste à « acheter » des idées avec une « monnaie à idées ». Chaque participant dispose de cent euros et pourra acheter les fonctionnalités ou les idées du backlog à la valeur qui lui donne. Plus la valeur cumulée attachée à une fonctionnalité est élevée, plus sa priorité sera élevée. En limitant le montant d’argent dépensé par participant, on gardera le vote équitable. Cette technique peut être mise en œuvre pour obtenir des résultats clairs et impartiaux.
Le Poker des priorités
Il s’agit d’une variante du Planning Poker qui se concentre sur la priorité des fonctionnalités. Les parties prenantes reçoivent une liste de fonctionnalités qui seront à prioriser sur une certaine échelle comme par exemple : 5 (priorité très élevée), 4, 3, 2, 1 (priorité très faible), les priorités étant matérialisées par un jeu de cartes distribuées à chaque participant. Le Scrum Master lit alors la description de chaque user story puis chaque participant lui attribue une priorité en plaçant l’une des cartes priorité face cachée en premier. Les cartes sont ensuite retournées simultanément. Il y aura forcément des écarts de score. Suit après une discussion afin d’atteindre un consensus sur l’importance de chaque user story. Il est aussi possible de calculer un score global pour chaque story pour déterminer les priorités relatives. Répétez l’exercice avec tous les éléments du backlog.
Priorisation en deux étapes
La priorisation du backlog est la prérogative du Product Owner et à ce titre implique généralement le client et les parties prenantes. Ces derniers sont mieux placés pour l’appréciation de la valeur business tandis que l’équipe technique peut fournir des estimations d’experts sur les aspects techniques. Il peut être alors logique que l’équipe de développement ait également son mot à dire. Ainsi, après avoir estimé la valeur et l’effort, il est essentiel d’avoir une discussion tous ensemble.
Les techniques évoquées ci-dessous permettent d’aligner les besoins business et les contraintes techniques.
Approche Business Vs Effort
Cette approche est assez facile à mettre en œuvre pour des projets de petite taille où l’on peut assez facilement diviser les fonctionnalités sur deux axes : l’axe « important / sans importance » et l’axe « simple / complexe ».
Le backlog est alors grossièrement distribué selon quatre catégories selon ces deux axes : « valeur commerciale » et « effort estimé » (mesuré en story points). Voici une représentation graphique de l’idée :
Mais alors, une fois cette cartographie réalisée, quelle catégorie développer en premier ?
Étant donné que la création de valeur le plus tôt possible est la clé du succès, nous commencerons par les stories « à haute valeur ajoutée et à effort réduit ». Celles-ci sont en général peu nombreuses et les livrer tôt permet de recevoir des retours tôt dans le projet. Ensuite, au fur et à mesure que l’équipe monte en puissance, il est bon de proposer des fonctionnalités « à haute valeur ajoutée, à haut niveau d’effort ». Celles-ci prendront une part importante du temps et de l’effort, mais elles seront essentielles pour générer de la valeur. Avec le temps, les exigences seront affinées, les estimations de chaque story seront plus faciles à réaliser et les risques liés à l’incertitude diminueront probablement. Le quadrant « faible valeur, faible effort » ne sont que des « nice-to-have » et ne feront pas beaucoup la différence. Leur mise en œuvre dépendra donc du budget disponible. Quant aux fonctionnalités du quatrième quadrant, elles ne verront peut-être jamais le jour.
En avoir pour son argent ou le « Banging-for-the-buck Score »
Pour certains projets, définir deux niveaux de priorité n’est pas toujours suffisant, alors cette technique peut donc s’avérer utile. Le calcul du score Banging-for-the-buck (BFTB) indique le rapport entre la valeur commerciale et l’effort. Une fois que tous les éléments du backlog ont été estimés en valeur business par les parties prenantes d’une part et en story points par les développeurs d’autre part, il est possible de calculer le score BFTB.
BFTB=Valeur Business/story points
Les fonctionnalités seront alors priorisées par rapport au score BFTB.
Cependant, il existe des cas où certaines fonctionnalités de faible valeur doivent d’abord être fournies pour assurer la viabilité du système : en termes simples, vous ne pouvez pas construire un toit sans d’abord construire les murs. C’est pourquoi les participants devront se réunir par la suite pour affiner le Backlog.