Le Product Backlog est la seule source des tâches effectuées par l’équipe Scrum. C’est une liste de fonctionnalités et d’améliorations de produit prévues. Sa forme est changeante et toutes les tâches incluses dans le Product Backlog ne seront pas nécessairement complétées. Il évolue au cours des discussions avec les parties prenantes. Il est également constamment amélioré. Cela signifie que plus on se rapproche de la date limite, plus une tâche devient détaillée.
Le Product Backlog est le plus grand des artéfacts Scrum. Il reflète l’état du travail sur un produit par rapport à l’objectif du produit. D’autre part, lorsque le travail sur un produit est terminé, son Backlog devient une liste complète des tâches effectuées par l’équipe Scrum pour créer le produit. Cependant, il ne contient pas de solutions techniques détaillées.
Le Product Backlog est créé lors des réunions du Product Owner avec les parties prenantes. Le Product Owner est le seul propriétaire et la personne responsable de cette source de tâches.
Le langage commercial caractérise les entrées du Product Backlog. En d’autres termes, elles décrivent la valeur du produit du point de vue des parties prenantes.
Les descriptions des tâches incluses dans la liste des tâches doivent être cohérentes et claires. Elles contiennent des fonctions et des améliorations du produit généralement présentées sous forme d’histoires utilisateur, auxquelles nous consacrons une entrée séparée. Ici, nous mentionnerons seulement qu’il s’agit de descriptions de fonctionnalités partielles du produit répondant aux questions concernant les problèmes suivants :
L’ordre des tâches incluses dans le Product Backlog change à mesure que le produit se développe. En travaillant dessus, l’équipe Scrum façonne et améliore ses fonctionnalités. Lorsqu’elle rencontre des obstacles, les actions mises en œuvre permettent à tous de réfléchir et de définir de futures solutions adéquates, et celles-ci changeront également en fonction d’obstacles imprévus. Par conséquent, il n’y a pas d’ordre clair et défini des actions, tout est changeant. L’amélioration du Product Backlog vise à son actualisation continue et à sa préparation pour les prochaines tâches. Pour cette raison, elle est continue.
Les tâches avec une date limite lointaine sont généralement de grands ensembles génériques. Leur description ne contient pas de détails, mais seulement un aperçu des fonctionnalités qui devraient être réalisées. Il est également possible de trouver parmi elles des tâches qui ne seront jamais terminées.
Les entrées du Product Backlog peuvent présenter des solutions alternatives. Et aussi les idées du client qui peuvent devenir obsolètes, non rentables ou pour d’autres raisons ne jamais entrer en phase de mise en œuvre. C’est pourquoi le Product Backlog est parfois plaisamment appelé la “liste de souhaits du client”.
Une autre raison des changements dans la forme du Product Backlog est la redéfinition des solutions. Parfois, il s’avère qu’un certain problème a déjà été résolu lors de la création d’une autre fonctionnalité du produit. Ou la fonctionnalité attendue est devenue redondante en raison de changements dans d’autres solutions.
Une des activités de base lors de l’amélioration du Product Backlog est de diviser les tâches contenues dans le Product Backlog en parties. Grâce à cela, l’aperçu général des fonctionnalités est présenté sous forme d’unités plus petites, plus détaillées et précisément définies.
Les tâches conçues pour une mise en œuvre plus proche deviennent plus détaillées. Elles deviennent également plus petites, contenant des détails de solutions. Les détails émergent lors du développement du produit. Et grâce à la connaissance de l’état actuel du produit et des attentes actuelles des parties prenantes, le Product Owner complète les tâches à venir avec leur description, ordre et taille. Ensuite, il sélectionne les tâches les mieux décrites pour le prochain Sprint Backlog.
Lorsqu’il travaille sur un produit, le Product Owner modifie et détaille le Product Backlog en coopération avec l’équipe de développement. Suivant les suggestions du Product Owner, lors de la planification du Sprint, l’équipe sélectionne les fonctionnalités à mettre en œuvre à partir du Product Backlog. Celles-ci sont ensuite transférées au Sprint Backlog et divisées en tâches à accomplir. Les tâches transférées au Sprint Backlog sont décrites dans un langage technique, qui est le plus utile pour les développeurs.
La taille des tâches est une métrique importante du point de vue de l’équipe de développement. Son estimation correcte devient particulièrement critique lors de la sélection des histoires utilisateur du Product Backlog vers le Sprint Backlog.
Au fil du temps, l’équipe de développement apprend à correctement estimer le temps et l’effort nécessaires pour compléter une histoire utilisateur spécifique. Cela s’exprime en jours, heures-homme ou points d’histoire et fournit une estimation d’une valeur appelée vitesse de l’équipe.
Le Product Backlog est une liste de tâches continuellement améliorée menant à l’objectif du produit. Le contenu du Product Backlog est généralement exprimé sous forme d’histoires utilisateur. Et plus le temps restant pour compléter une tâche est court, plus :
L’équipe Scrum prend soin des tâches. Le Product Owner gère et modifie le Product Backlog.
Si vous aimez notre contenu, rejoignez notre communauté de travailleurs acharnés sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
En tant que chef de projet, Caroline est une 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 pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.
Les entreprises luttent pour gérer une vaste quantité de contenu publié en ligne, des publications…
À l'ère de la transformation numérique, les entreprises ont accès à une quantité sans précédent…
Saviez-vous que vous pouvez obtenir l'essence d'un enregistrement de plusieurs heures d'une réunion ou d'une…
Imaginez un monde où votre entreprise peut créer des vidéos engageantes et personnalisées pour n'importe…
Pour tirer pleinement parti du potentiel des grands modèles de langage (LLMs), les entreprises doivent…
En 2018, Unilever avait déjà entrepris un voyage conscient pour équilibrer les capacités d'automatisation et…