Jackpot, vous venez de décrocher un nouveau poste de PO ou PM. Mais dès vos premiers jours, c’est le drame… le backlog compte bien plus de 150 items, nombre maximum recommandé par le Scrum Guide, et sont tous marqués d’une étiquette rouge Must Have ou d’une Priorité Highly Important…
Les feedbacks et suggestions de nouvelles fonctionnalités de vos utilisateurs pleuvent et la rétention de vos clients est en jeu…
L’équipe commerciale vous abreuve de ces fonctionnalités, qui si elles étaient développées très rapidement, pourraient leur permettre de closer des deals…
Les investisseurs ne jurent que par cette fonctionnalité et votre big boss vous annonce : “On met tout de côté, il faut absolument prioriser cette feature pour les convaincre d’avancer avec nous !”…
Vous vous y perdez, entre la priorisation d’un backlog Produit, backlog Tech et backlog bug…
Voici des éléments déclencheurs -parmi tant d’autres- d’une Guerre du Backlog. Vous voilà donc engagé, tels les deux soldats britanniques Schofield et Blake, dans une bataille à proprement parler impossible. Vous êtes investi d’une mission qui pourrait bien empêcher une attaque dévastatrice sur le Produit !
Et pour vous lancer dans cette véritable course contre la montre, vous faire des alliés et pacifier le développement du Produit, voici trois premières méthodes de priorisation du Backlog qui pourront très certainement vous accompagner.
Les éléments de votre backlog ne sont pas encore priorisés ou vous voulez rebattre les cartes et vérifier les priorités établies. Une priorisation MoSCoW peut être un premier angle d’attaque simple.
Il s’agit de classer les éléments de votre backlog dans les catégories suivantes :
M – Must have : les éléments vitaux pour votre produit
S – Should have : les éléments importants, mais pas vitaux pour votre produit
C – Could have : les éléments qui pourront être développés s’ils n’ont pas d’impacts sur les tâches vitales
W – Won’t have : éléments avec moins ou pas de valeur immédiate et qui pourront être réévalués dans une version ultérieure du produit
Mais comment procéder pour ne pas obtenir tous les éléments de votre backlog en Must Have ?
1. Regroupez vos forces en un seul et même bataillon lors d’un atelier. Équipes métier, Sales, Marketing, Support client… Assurez-vous d’avoir un échantillon représentatif des différentes parties prenantes autour de la table, y compris les décideurs pour ne pas revenir sur les priorités établies quelques jours seulement après l’atelier.
N’hésitez pas à inclure l’équipe de développement à cet atelier pour leur donner une meilleure vision produit mais également afin qu’ils puissent partager la complexité technique de tel ou tel élément du backlog aux parties prenantes en cas de difficulté d’arbitrage
2. Préparer et afficher sur des post-its les éléments du backlog à prioriser, les post-its doivent être visibles par tous les participants
3. Afficher sur un board les catégories Must, Should, Could et Won't dans lesquelles les participants devront placer les post-its
Les participants sélectionnent des post-it et viennent les placer dans les différentes catégories, dans un premier temps sans échanger. Ils devront dans un second temps échanger sur les post-its qui font débat. Il est important de bien cadrer l’atelier pour équilibrer le nombre de post-its dans les différentes catégories. Si trop de tickets sont encore en Must Have ou Should Have, demandez aux participants de débattre à nouveau sur les éléments en Must Have pour n’en garder qu’un nombre défini. Répétez l’opération sur les Should Have jusqu’à l’obtention d’un nombre cohérent d’éléments dans chaque catégorie.
Cette méthode peut s’avérer inefficace si les différentes parties prenantes manquent d’objectivité ou si les relations sont très conflictuelles entre les différents services. Elle présente néanmoins l’intérêt d’aligner tous les métiers sur des objectifs communs lors d’un atelier assez simple à mettre en place. Cet atelier pourra être répété à intervalle régulier et est un bon moyen d’engager vos parties prenantes !
Et si la valeur business, l’utilité d’un élément du backlog, devenait un élément clé de votre stratégie de priorisation du backlog ? Avec la business value, on va un peu plus loin que dans la méthode MoSCoW en scorant tous les éléments du backlog sur la valeur business de la même manière que vous estimez des points de complexité avec l’équipe de développement.
À vous de trouver la définition la plus adaptée à votre produit, il peut s’agir de la valeur :
Commerciale : acquisition client, upsell, rétention etc...
Corporate : chiffre d’affaires, notoriété, image de marque...
Métier : gain en efficacité, moins de support utilisateur...
Utilisateur (Customer Value) : le produit est plus friendly, présente les fonctionnalités clés pour son utilisation au quotidien, la satisfaction utilisateur est bonne...
Client : valeur du produit pour celui qui achète le produit ou service qui n’est pas forcément le end-user comme par exemple les tableaux de bord, le ROI de l’outil etc…
L’idéal est de prendre en compte l’ensemble de ces éléments lors de l’estimation de la business value d’un élément du backlog et ce en réunissant bien les différentes parties prenantes.
1. Préparez vos éléments de backlog à scorer et votre jeu de carte de poker planning
2. Regroupez vos parties prenantes lors d’un atelier
3. 1, 2, 3 - Scorez : comme dans une session de poker planning qu’on peut appeler ici priority poker, un élément du backlog est présenté et les participants choisissent une carte numérotée pour estimer la valeur business
4. Si les valeurs choisies divergent, les participants échangent et démarrent ce challenge collectif de prioriser telle ou telle US
Astuce : si vous êtes à distance, le poker planning ou priority poker est toujours possible sur Voting Poker ou Planitpoker
La business value va donner du sens à l’équipe. Pourquoi cette US est prioritaire par rapport à une autre ? Je dois choisir entre deux US à développer dans le sprint en cours, et si je commençais par celle qui a le plus de valeur business ? Vous pouvez ainsi décider de rajouter cet indicateur sur vos US dans Jira à l’aide d’un champ personnalisé (custom fields).
Cela vous permettra de mesurer la valeur business créée, de l’afficher, de communiquer sur celle-ci. La business value est un indicateur bien plus intéressant que la vélocité qui a d’ailleurs pour vocation à rester interne à l’équipe de développement. Vous pouvez tout à fait créer un burnup Chart dédié à la valeur créé dans le sprint.
La business value est une méthode de priorisation assez puissante et qui reste somme toute assez simple à mettre en place. Elle permettra au PO ou PM de justifier factuellement la priorisation des fonctionnalités auprès des différentes parties prenantes, acteurs eux-même de la définition de la business value.
En tant que PO, la business value vous permettra également de communiquer auprès des différentes parties prenantes sur les tâches techniques qui font partie intégrante des éléments du backlog et qui étaient jusqu’ici obscurs pour eux. “Il faut faire une migration vers telle techno, mais pourquoi ?” Les ateliers de priority poker vous permettront de mettre en lumière l’importance des tâches techniques aux équipes métiers.
La business value pourra enfin améliorer la perception de l’équipe de développement qui ne sera plus uniquement un centre de coût mais un centre de création de valeur.
Attention la business value doit nécessairement être réévaluée régulièrement, à l’aune de l’arrivée d’un nouveau concurrent sur le marché, d’une évolution dans les comportements des utilisateurs, d’une demande de nouvelle fonctionnalité à prioriser etc… L’indicateur de la business value n’est jamais figé !
Par ailleurs, soyez vigilants à ce que la business value ne devienne pas un indicateur de performance de l’équipe car la vélocité en terme de business value sera forcément amenée à décroître à mesure que vous allez dépiler les éléments du backlog.
Si la tactique MoSCoW ou la priorisation par la business value ne portent pas leurs fruits, la méthode WSJF, issue de SaFe, peut faire ressortir des priorités dans la multitude de fonctionnalités en Must Have de votre backlog ! Le WSJF a pour objectif de faire ressortir les features les plus importantes et les plus courtes / rapides à développer en top de votre backlog. Si vous hésitez donc entre plusieurs fonctionnalités Highly Important pour le business, le WSJF peut vous faire gagner une bataille.
Le calcul de l’indicateur WSJF tiendra compte des valeurs suivantes :
Business value : la valeur métier de la fonctionnalité estimée avec les parties prenantes
Niveau d’urgence : la fonctionnalité doit-elle être livrée rapidement ? Quelle criticité pour cette fonctionnalité ?
Réduction des risques / Facilitation des développements : sécurisation de l'application, système de déploiement qui n'implique aucune interruption de service par exemple
Taille de la fonctionnalité à développer : points de complexité estimés par l’équipe de développement
Pour chacune des valeurs, vous pourrez utiliser la suite de Fibonacci pour les noter.
Une fois les différentes valeurs notées, vous voilà prêt pour le grand calcul.
On calcule d’abord le coût du délai pour chacune des fonctionnalités : Coût du délai = Business value + Niveau d’urgence + Réduction des risques
Vous y êtes presque, plus qu’une division pour obtenir le résultat : WSJF = Coût du délai / Taille de la fonctionnalité
Si la criticité ou la réduction du délai est difficile à mesurer sur votre produit, vous pouvez tout à fait utiliser uniquement la business value : Business Value / Taille de la fonctionnalité
Cela peut vous permettre de prioriser simplement des User Stories avec des Business Values sensiblement proches en fonction de la facilité à développer et rapidité à livrer une feature.
Pour résumer, la méthode WSJF peut donc vous aider à légitimer vos choix et votre priorisation notamment auprès des équipes dirigeantes, des équipes métier. Cependant le calcul des différents indicateurs peut se révéler chronophage donc vous pouvez choisir de ne l’utiliser que sur des Epics ou Roadmap Features.
Les méthodes RICE, KANO et des ruses de Sioux en termes d'organisation feront l'objet d'un second article à découvrir très prochainement ! Le story mapping et l'impact mapping sont également des méthodes très efficaces à explorer. Mais retenez que le plus important est de trouver la méthode qui fonctionne avec vos parties prenantes, votre équipe, votre produit. Alors restez agiles, testez, changez, mixez les méthodes en fonction de vos objectifs et de la maturité de votre produit ! La priorisation d'un backlog ne se fait pas en un seul plan séquence à la Sam Mendes, alors itérez ! et ne manquez pas la suite de la Guerre du Backlog n'aura pas lieu !
Et enfin rappelez-vous que la communication et l’engagement des différents corps de métier dans la stratégie produit sont clés. En termes de priorisation, il n’y a pas d’ennemis, il faut avant tout faire front avec toutes les parties prenantes pour développer un produit qui apporte une plus grande satisfaction aux utilisateurs !
Auteur(s)
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
La qualité est un enjeu très important dans le développement logiciel, cet article vous permettra de (re)découvrir les impacts de la non-qualité, les bienfaits de la qualité et les bonnes pratiques qualité.
Aujourd’hui on parle de product management pour qualifier tout et n’importe quoi, ce qui entraîne la mise en place d’organisations produits sur des bases bancales. Quelles sont les principales erreurs commises ? Comment les éviter ? La liste n’est pas exhaustive mais vous permettra assurément de mieux appréhender votre méthodologie produit.
Cet article présente mes méthodes préférées pour bien appréhender un nouvel environnement de travail, incluant des outils pratiques comme le rapport d'étonnement, le Value Stream Mapping, le mandat de mission, la matrice des attendus et les Moving Motivators, afin de faciliter l'intégration, améliorer les processus et renforcer la collaboration au sein de l'équipe