Guide de mêlée | 18. Qu'est-ce que le Product Backlog ?

Le Product Backlog est la seule source de tâches effectuées par l'équipe Scrum. Il s'agit d'une liste des fonctionnalités et améliorations prévues du produit. Sa forme est variable et toutes les tâches incluses dans le Product Backlog ne seront pas terminées. Il évolue au cours des discussions avec les parties prenantes. Il est également constamment amélioré. Cela signifie que plus la date limite est proche, plus une tâche devient détaillée.

Qu'est-ce que le carnet de produit ? - table des matières:

1. Introduction
2. Que contient le Product Backlog ?
3. La forme du Product Backlog
4. Amélioration du carnet de produit
5. Sommaire

Introduction

Le backlog de produit est le plus grand des artefacts Scrum. Il reflète l'état d'avancement du travail sur un produit concernant 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.

Que contient le Product Backlog ?

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 le responsable de cette source de tâches.

Le langage métier caractérise les entrées du Product Backlog. En d'autres termes, ils décrivent la valeur du Produit du point de vue des Parties Prenantes.

Les descriptions de tâches incluses dans la liste des tâches doivent être cohérentes et claires. Ils contiennent des fonctionnalités et des améliorations du Produit généralement présentées sous forme de User Stories auxquelles nous consacrons une rubrique à part. Ici, nous mentionnerons seulement qu'il s'agit de descriptions de fonctionnalités partielles du produit répondant aux questions sur les problèmes suivants :

• La portée des modifications du produit
• Le but de la modification du Produit
• Le type d'utilisateur pour qui cette modification intervient

La forme du Product Backlog

L'ordre des tâches incluses dans le Product Backlog change au fur et à mesure que le Produit se développe. Tout en y travaillant, l'équipe Scrum façonne et améliore ses fonctionnalités. En cas d'obstacles, ses actions mises en œuvre permettent à tous de réfléchir et de définir des solutions futures adéquates, et celles-ci changeront également en fonction d'un nouvel obstacle imprévu. Par conséquent, il n'y a pas d'ordre d'actions clair et défini, tout est modifiable. L'amélioration du Product Backlog vise sa mise à jour continue et sa préparation pour les prochaines tâches. Pour cette raison, il est continu.

Les tâches avec une échéance éloignée 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 doivent être réalisées. Il est également possible de trouver parmi eux des tâches qui ne se termineront jamais.

Les entrées dans le Product Backlog peuvent présenter des solutions alternatives. Et aussi les idées du Client qui peuvent devenir obsolètes, non rentables ou pour une autre raison n'entrent jamais dans la phase de mise en œuvre. C'est pourquoi le Product Backlog est parfois appelé en plaisantant 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.

L'une des activités de base lors de l'amélioration du Product Backlog consiste à diviser les tâches contenues dans le Product Backlog en plusieurs parties. Grâce à cela, le schéma général des fonctionnalités est présenté sous la forme d'unités plus petites, plus détaillées et définies avec précision.

Les tâches conçues pour une mise en œuvre plus étroite deviennent plus détaillées. Ils deviennent également plus petits, contenant des détails sur les solutions. Les détails apparaissent au cours 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, sélectionne les tâches les mieux décrites pour le prochain Sprint Backlog.

Amélioration du carnet de produit

Lorsqu'il travaille sur un produit, le Product Owner modifie et détaille le Product Backlog en collaboration 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 à implémenter à partir du Product Backlog. Ils sont ensuite déplacés vers le Sprint Backlog et divisés en tâches à accomplir. Les tâches déplacées vers le Sprint Backlog sont décrites dans un langage technique, ce qui est le plus utile pour les Développeurs.

La taille des tâches est une mesure importante du point de vue de l'équipe de développement. Sa bonne estimation devient particulièrement critique lors de la sélection des User Stories du Product Backlog au Sprint Backlog.

L'équipe de développement apprend au fil du temps à estimer correctement le temps et les efforts nécessaires pour terminer une User Story spécifique. Ceci est exprimé en jours, heures-personnes ou Story Points et fournit une estimation d'une valeur appelée Team Velocity.

Sommaire

Le Product Backlog est une liste continuellement améliorée de tâches menant à l'objectif du produit. Le contenu du Product Backlog est généralement exprimé sous la forme de User Stories. Et plus le temps restant pour terminer une tâche est court, plus :

• La description du poste est plus détaillée
• La portée de la tâche est plus petite
• La portée de la tâche est mieux définie

L'équipe Scrum s'occupe des tâches. Le Product Owner gère et modifie le Product Backlog.

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