POURQUOI UN PRODUCT BACKLOG ?
Le Product Backlog est:
- Le plus important des artefact Scrum et de toute démarche agile.
- La représentation du travail à faire. Il donne une vision partagée de ce que l’équipe va produire. Il assure ainsi un suivi transparent des travaux et des “exigences” du client vis-à-vis du produit final attendu.
- Le QUOI d’un projet agile. A ce titre, il doit être établi, maintenu, mis à jour et diffusé le plus rapidement possible.
- La source unique des exigences de tous les changements à effectuer sur le produit. Le Product Owner est responsable du Product Backlog : de son contenu, de sa diffusion ainsi que de son ordonnancement.
- Le Product Backlog n’est pas un document de spécification fonctionnelle : il décrit plus le QUOI que le COMMENT. De la documentation fonctionnelle supplémentaire peut donc être nécessaire sur un projet.
QUAND FAIRE UN PRODUCT BACKLOG ?
- Le Product Backlog doit être établi dès le début du projet, soit par le Product Owner du côté du client, soit à partir de la phase d’avant-vente.
- Au cours des premiers ateliers, le Product Owner ajoute au Product Backlog les exigences initialement identifiées.
- Le Product Owner met régulièrement à jour le Product Backlog jusqu’à la fin du projet.
- Le Product Backlog persiste aussi longtemps que le produit existe, il n’a pas de fin.
QUI CRÉE ET MAINTIENT LE PRODUCT BACKLOG ?
- Le Product Owner est responsable du Product Backlog : de son contenu, de sa diffusion ainsi que de son ordonnancement.
- Le Product Backlog n’est pas fixe. Dans un contexte agile, il évolue en accord avec les changements du produit et de son environnement d’utilisation.
- Le Product Backlog est donc flexible, subissant des modifications continues pour s’aligner avec les besoins évolutifs du produit en vue d’apporter de la valeur.
COMMENT CONSTRUIT-ON UN PRODUCT BACKLOG ?
Contenu Du Product Backlog
Le Product Backlog liste les items qui définissent le produit :
- Fonctionnalités principales : Les fonctionnalités clés du produit ou du projet.
- Tâches techniques : Les travaux techniques requis pour la mise en œuvre des fonctionnalités.
- Bugs et corrections : Les problèmes à résoudre et les corrections à apporter.
- Améliorations : Les suggestions d’améliorations ou d’optimisations du produit.
- Exigences métier : Les exigences fonctionnelles et non fonctionnelles du client ou des utilisateurs.
Dans un cadre agile, nous recommandons l’écriture des items sous forme de User Stories.
Les éléments du Product Backlog sont classés en fonction de leur priorité Business. L’estimation intervient ultérieurement, lors de la sélection des éléments à inclure dans un sprint donné.
Le Sprint 0
Le Product Owner organise plusieurs réunions pour créer le Product Backlog. Les méthodes utilisées incluent des:
- Ateliers de travail.
- Entretiens individuels.
- Utilisation de questionnaires.
Chaque rencontre avec les utilisateurs doit avoir un objectif précis, convenu au moment de la planification des rendez-vous. Si nécessaire, le Product Owner peut être assisté par le Quality Analyst et/ou le Business Analyst.
Il est possible d’organiser une réunion à mi-chemin du Sprint 0 afin de présenter les premières avancées.
En général, lors du Sprint 0, on identifie le Minimum Viable Product (MVP), qui consiste à définir le produit avec le nombre minimal de fonctionnalités nécessaire pour satisfaire l’utilisateur et obtenir des retours initiaux.
Formalisation
Le Product Backlog peut être créé sous tableau Excel, avec pour chaque item du Product Backlog , au moins :
- Description : En tant que <rôle>, je peux <action> afin de <résultat>
- Priorité: au sein du Product Backlog
- Taille : en charge et/ou en complexité
- Une valeur métier : Valeur Business de la User Story
- Les critères d’acceptance : Etant donné <un état de l’application>, quand <action> alors <résultat>
- La référence de l’Epic
D’autres colonnes peuvent être rajoutées en mode ad’hoc, au fur et à mesure, comme une colonne de répartition par itération, une colonne de statut (“New”, “Ready”, “In Progress”, “Done”)
Affinage (Grooming) du Product Backlog
Les premiers éléments du Product Backlog sont plus détaillés, permettant une estimation plus précise, tandis que les éléments ultérieurs sont moins détaillés.
Les éléments du Sprint prochain sont affinés pour être réalisables en un Sprint et sont prêts pour la planification.
Attention !
- En cas d’urgence extrême.
- Lorsqu’une User Story est devenue obsolète.
- Après négociation, en échange de la suppression d’une User Story de taille équivalente qui n’a pas encore commencé.
- En veillant à ne pas surcharger l’équipe, car elle s’est engagée sur un périmètre simple et bien défini.
Il est possible de modifier le reste du Product Backlog, mais il est essentiel de prendre en compte le périmètre, notamment dans le cadre d’un projet au forfait.
Estimation du Product Backlog
Le processus d’estimation du Backlog est un processus continu qui se déroule comme suit :
- L’estimation initiale est effectuée lors de la phase d’avant-vente, ce qui représente la taille initiale du Backlog.
- Lors des réunions de Sprint Planning et des revues du Product Backlog, l’estimation est révisée pour refléter la taille actuelle.
L’équipe de développement est responsable de l’estimation, bien que le Product Owner puisse influencer en fournissant des informations et des conseils, ce sont les membres de l’équipe qui fournissent l’estimation finale.
Focus Sur les Tâches Techniques
Il est essentiel d’inclure les tâches techniques dans le Product Backlog et de les estimer.
Exemple de tâche technique non fonctionnelle:
En tant que développeur front-end, je souhaite optimiser les images du site web en utilisant la compression d’images sans perte, afin que le site se charge plus rapidement pour les utilisateurs et améliore l’expérience utilisateur.
Recommandations: Les Erreurs à Eviter
Les dix erreurs à éviter dans la gestion du Product Backlog :
- Ne pas avoir de Product Backlog.
- Avoir plusieurs Product Backlogs pour un seul produit (ou d’autres sources parasites).
- Ne pas partager le Product Backlog avec toute l’équipe.
- Ne pas actualiser le Product Backlog pendant le projet.
- Ne pas prioriser les éléments ou leur donner des priorités égales.
- Avoir des éléments trop précis et/ou trop vagues dans le Product Backlog (critères INVEST).
- Ne pas avoir suffisamment d’éléments prêts (“Ready”) pour alimenter l’équipe de développement lors du prochain Sprint.
- Ajouter constamment de nouveaux éléments sans évaluer leur valeur ou leur priorité.
- Ne pas impliquer activement le Product Owner dans la gestion et la mise à jour du Product Backlog.
- Ignorer les retours des utilisateurs finaux lors de l’ajout ou de la modification d’éléments dans le Product Backlog
0 commentaires