Guide de mêlée | 40. Nourrir le carnet de produit

Le Product Backlog nurturing est l'une des principales tâches d'un Product Owner. Le processus de développement comprend la formulation, le détail et l'ajout de nouvelles User Stories au Product Backlog. Cependant, la plus importante des tâches de maturation est de s'assurer que les entrées placées dans le Backlog sont dans le bon ordre, c'est-à-dire deviennent prioritaires.

Product Backlog nurturing – table des matières :

1. Introduction
2. Objectif du Product Backlog nurturing
3. Erreurs dans la maintenance du Product Backlog
4. Maintenance du backlog vs métriques utilisées dans Scrum
5. Sommaire

Introduction

Le backlog de produit est l'un des artefacts de Scrum. Il contient une liste prioritaire des travaux nécessaires à la création d'un produit. En d'autres termes, il s'agit d'une liste de User Stories nécessaires pour atteindre l'objectif du produit. Vous pouvez trouver une description détaillée de ce que sont les User Stories dans cet article. Et voici les détails sur les caractéristiques et comment maintenir le Product Backlog.

Le Product Backlog nurturing porte également les noms suivants :

• Priorisation du backlog,
• Raffinement du backlog,
• Mise à l'échelle du backlog.

Objectif du Product Backlog nurturing

Le Product Owner gère le Product Backlog. Les compétences clés comprennent la hiérarchisation des tâches à l'approche de leur date d'échéance. En effet, l'objectif du Product Backlog nurturing est de s'assurer que les fonctionnalités du produit ont la plus grande valeur commerciale, c'est-à-dire celles qui sont les plus essentielles du point de vue du client, sont en haut de la liste des tâches. Et leur description est claire et détaillée afin que leur implémentation puisse commencer dès le prochain Sprint.

Le Product Backlog peut être mis à jour quotidiennement si nécessaire. Le Product Owner peut ajouter de nouvelles User Stories au Product Backlog après avoir discuté avec les Parties Prenantes et l'Equipe de Développement, ou en tirant des conclusions et en reformulant les User Stories déjà écrites dans le Product Backlog.

La mise à jour obligatoire du Backlog est l'une des tâches effectuées lors de la Sprint Review. Nous avons décrit ce processus en détail dans cet article. Habituellement, lors de cette réunion, l'équipe Scrum ne discute pas seulement des tâches à accomplir lors du prochain Sprint. Il spécifie également de manière préliminaire les User Stories et leur mise en œuvre dans les deux ou trois prochains Sprints. Cette façon de faire permet à l'équipe Scrum et à ses activités d' avoir une vision plus large de la direction à long terme. Il permet de penser les tâches en cours d'exécution du point de vue de leur développement dans les Sprints suivants.

Erreurs dans la maintenance du Product Backlog

L'un des problèmes les plus courants concernant le Product Backlog nurturing est de lui permettre de se développer de manière incontrôlable. En effet, lors du travail sur le produit, diverses fonctionnalités et tâches supplémentaires proposées à la fois par les parties prenantes et les membres de l'équipe Scrum apparaissent spontanément. Par conséquent, limiter la croissance du périmètre du Product Backlog (scope creep) est l'une des tâches les plus importantes effectuées par le Product Owner. Les erreurs les plus courantes des Product Owners concernent :

1. S'écarter de l'objectif produit - ajouter trop d'idées au backlog produit au-delà de l'objectif produit de base n'est pas une bonne pratique, car cela réduit considérablement sa lisibilité. Il est préférable de collecter des idées de fonctionnalités supplémentaires dans un document séparé.
2. Duplication de contenu - entrer des idées répétées ou très similaires de différentes parties prenantes dans le Backlog - avant d'ajouter une autre entrée au Backlog, le Product Owner doit s'assurer que la nouvelle entrée ne duplique aucune de celles existantes.
3. Manque d'une perspective plus large - vous devez classer les entrées du Product Backlog en fonction de leur valeur concernant l'objectif du produit. Cependant, gardez à l'esprit que la hiérarchisation doit prendre en compte les prochains sprints afin que les tâches effectuées dans un sprint donné soient liées de manière transparente à la fois au sprint précédent et au sprint qui le suit immédiatement.

Vous ne pouvez pas éviter les erreurs de ce genre. Cependant, la connaissance de leur occurrence peut rendre le Product Owner plus prudent quant à l'ajout de nouvelles User Stories au Product Backlog pour trouver le bon équilibre. C'est parce que c'est aussi une erreur de couper trop le Backlog et d'éliminer les entrées qui contiennent des tâches similaires qui diffèrent. Par exemple, décrire des fonctionnalités de produit similaires qui diffèrent considérablement dans l'application.

Maintenance du backlog vs métriques utilisées dans Scrum

Le Product Backlog contient une description du travail restant tout au long du projet. Cependant, seul un Backlog mis à jour et régulièrement alimenté peut estimer avec précision le rapport entre la quantité de travail achevée et le total. Pour décrire la quantité de travail accompli, vous devez appliquer le Burndown Chart, dont nous avons parlé dans cet article.

Une autre métrique populaire pour décrire le travail de l'équipe Scrum est la vélocité. Vous pouvez le mesurer en comparant le nombre d'entrées du Product Backlog converties en Incrément au cours d'un même Sprint. Nous avons décrit Velocity plus en détail dans cet article.

Sommaire

Le Product Owner réalise le Product Backlog Nurturing. Lorsque le Product Backlog est bien entretenu, l'équipe Scrum a une vision claire du travail qui reste. Il peut également obtenir une perspective plus large et prospective de ce à quoi ressemble le chemin vers l'objectif du produit. C'est pourquoi le Product Owner doit s'assurer que les User Stories incluses dans le Product Backlog sont par ordre de priorité d'achèvement. Et aussi que les tâches à accomplir dans les prochains Sprints soient décrites dans les moindres détails.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit