Dans ce chapitre, vous allez apprendre toutes les subtilités du Product Backlog lors d'un développement agile. Vous savez déjà qu'il se compose de User Stories, autrement dit qu'il est le recueil des besoins utilisateurs. Ces User Stories contiennent aussi les tâches : le Product Backlog est donc une liste ordonnée de tout ce qui est requis pour développer le produit ou le service de votre client.
Le Product Backlog pour l'équipe agile
Avec le Product Backlog, vous transformez les intentions du projet en commandes explicites. Cette approche fonctionnelle réunit sur des affichettes tout ce que doit savoir votre équipe agile :
les besoins ;
les améliorations ;
les correctifs à apporter.
Partagez le Product Backlog avec votre client et toutes les parties prenantes du projet. Les User Stories et les tâches y sont décrites, classées et évaluées afin de faciliter votre gestion quotidienne. 📝
En développement agile, vous avez pour objectif de produire de la valeur en priorité. Vos clients auront tous le même souhait : « Je veux une application qui m’apporte une vraie valeur » ! Analysez chaque tâche du product backlog en fonction de cette valeur, afin de faciliter les arbitrages et la priorisation du travail. 😎 Votre calcul de la valeur sera composé de critères pondérés afin de déterminer objectivement les gains attendus : qualité, notoriété, renforcement du savoir-faire, adéquation au marché, etc.
Le Product Backlog est un recueil des besoins qui peut évoluer au fur et à mesure que le produit ou le service est développé. Motivez votre équipe à le garder toujours hiérarchisé afin de satisfaire votre client ! Posez-leur chaque jour la question radicale : Quelle serait la fonction à absolument développer aujourd'hui si vous deviez obligatoirement livrer le produit ou le service demain ?
Le Product Backlog pour le coach agile
Dans un premier temps, vous pouvez utiliser la méthode MoSCoW afin de prioriser les besoins ou les exigences du Product Backlog. Votre objectif est que l'équipe s'accorde sur l'importance des fonctionnalités à réaliser en respectant des délais raisonnables. Estimez la valeur d'une User Story ou d'une tâche avec l'un des 4 niveaux de cette échelle :
“Must have”, les fonctionnalités indispensables.
“Should have”, les fonctionnalités importantes.
“Could have”, les fonctionnalités de confort.
“Want to have but Won’t have”, les fonctionnalités souhaitables, mais reportées.
Votre équipe affecte ces priorités au Product Backlog afin de garantir les intérêts de votre client. Elle réalise les tâches M, puis les tâches S et C. Lorsque les délais (ou le budget) ne peuvent pas être respectés, les tâches C seront les premières à être annulées. ⏱ La méthode MoSCoW s’applique dans un temps délimité, afin de focaliser vos efforts sur les tâches les plus importantes.
Dans un second temps, un autre modèle de priorisation peut vous aider à calculer la valeur des User Stories du Product Backlog. Appliquez un questionnaire matriciel de satisfaction en vous posant ces 2 questions opposées pour une même fonctionnalité :
Que pensez-vous du produit s’il contient la carte interactive ❔
Que pensez-vous du produit s’il ne contient pas la carte interactive ❔
Vos 2 réponses se font à partir de ces 5 propositions, afin d'estimer la valeur :
Cela me ferait plaisir.
Ce serait un minimum.
Je n’ai pas d’avis.
Je l’accepterais.
Cela me dérangerait.
En croisant vos 2 réponses, vous obtenez une matrice composée de 6 critères :
Obligatoire.
Exprimée.
Latente.
Indifférente.
Incertaine.
Annulée.
J'ai classé ces critères dans l'ordre décroissant, c'est-à-dire du plus au moins prioritaire lors de votre développement agile. Dans l'image ci-dessous, les cases vertes correspondent donc aux fonctionnalités indispensables (obligatoires, exprimées ou latentes), les cases jaunes à celles de confort (indifférentes), et les cases rouges aux moins importantes (incertaines ou annulées). #MoSCoW
La priorisation du Product Backlog est une compétence centrale en développement agile. La méthode MoSCoW, inventée par l'informaticien anglais Dai Clegg, est un bon moyen pour faciliter les échanges entre l'équipe et le client.
En résumé
Vous priorisez la valeur du produit ou du service dans un Product Backlog évolutif, afin de faciliter votre développement agile.
En qualité de coach agile, vous utilisez d'abord la méthode MoSCow, puis le questionnaire matriciel de satisfaction ou des techniques d’évaluation plus singulières, afin de challenger votre équipe et votre client.
Dans le chapitre suivant, c'est la complexité du projet que vous allez appréhender, afin de garantir toute la qualité de notre travail collaboratif.
