Pourquoi ?
- Le Product Backlog doit constamment refléter le travail en cours ainsi que les futures fonctionnalités, même si elles ne seront pas toutes implémentées à la fin du projet.
- Il est important de noter que tous les éléments du Product Backlog ne nécessitent pas le même niveau de détail. Il peut contenir des User Stories prêtes à être développées, mais aussi des fonctionnalités, des tâches techniques et éventuellement des anomalies (bugs).
- L’objectif de la Product Backlog Review (Product Backlog Refinement ou Grooming dans Scrum) est d’enrichir les éléments du Product Backlog en leur ajoutant des détails, des estimations et des priorités.
Attention !
Pour simplifier nos rituels, nous confondons Backlog Review, Refinement et Grooming, bien que certains agilistes les distinguent
Quand Faire une Product Backlog Review ?
La Product Backlog Review est une réunion qui se produit une ou deux fois pendant chaque Sprint, généralement au milieu du Sprint plutôt qu’au début. Elle dure environ 2 heures.
Pendant cette réunion, l’élément d’entrée principal est le Product Backlog qui a été priorisé. L’objectif de la réunion est de passer en revue le Product Backlog et de le mettre à jour si nécessaire.
À la fin de la Product Backlog Review, le résultat est un Product Backlog affiné et amélioré.
Cela signifie que l’équipe a une compréhension plus claire des éléments du Product Backlog, ce qui facilite la planification lors de la Sprint Planning pour le Sprint à venir.
Le Sprint Backlog, lui, est créé lors de la Sprint Planning.
Fréquence
Une à deux fois par Sprint plutôt au milieu de Sprint qu’au début
1
Durée
Environ 2 heures.
2
Entrants
Product Backlog priorisé
3
Sortants
Product Backlog revu et corrigé
4
Fréquence
Une à deux fois par Sprint plutôt au milieu de Sprint qu’au début
1
Durée
Environ 2 heures.
2
Entrants
Product Backlog priorisé.
3
Sortants
Sprint Backlog revu et corrigé.
4
Qui Participe à La Product Review ?
La Product Backlog Review est un travail collaboratif entre le Product Owner, la Dev Team et le Business Analyst.
Les personnes suivantes participent à la revue :
- Scrum Team : Product Owner, Scrum Master, Dev Team (au complet ou pas)
- Le cas échéant : Tech Lead, Business Analyst, Quality Analyst.
- Toute personne susceptible d’apporter de la valeur ajoutée à ces réunions.
Comment Anime-t-on Une Product Backlog Review ?
Points à Adresser Pendant la Revue
La Product Backlog Review avec le Product Owner porte sur les aspects suivants. Chacun de ces points sera abordé avec plus de détail.
Vision
- Travail sur la vision pour revue et mise à jour
Product Backlog
- Travail sur les éléments du Product Backlog:
- Les nouveaux
- Les abandonnés
- Les existants
Release
- Travail sur le Release Plan
Points de Blocage
- Liste avec des éléments associés (qui sont donc en état de blocage technique et/ou fonctionnel)
Note : Dans un processus agile, les anomalies et les correctifs sont considérés comme entrées du Product Backlog.
Travail sur la Vision
Il s’agit de vérifier si la Product Vision a changé :
- Revue de la vision actuelle.
- Identification des facteurs de changement de la vision.
- Mise à jour de la vision par rapport à ces changements.
- Identification des impacts sur le “Release Plan“
Travail sur les Eléments du Product Backlog
Tous les éléments du Product Backlog (User Stories, Taches Techniques, Bugs…) peuvent être traités lors de cette revue.
Les éléments existants:
- Vérification de la compréhension du besoin par l’équipe
- Eventuellement réestimation si nécessaire
- Ajout/Suppression d’un élément du Product Backlog en fonction de la réévaluation (ajout si revue à la baisse, suppression si revue à la hausse)
Les éléments abandonnés:
- Explication des raisons de l’abandon.
- Analyse de l’impact de cet abandon sur le périmètre du projet, y compris les changements potentiels.
- Remplacement par un élément de même complexité le cas échéant.
Les nouveaux éléments:
- Vérification de la compréhension du besoin par l’équipe
- Estimation des éléments en Story Points
- Planification dans un prochain Sprint si possible
- Suppression d’un élément de complexité équivalente le cas échéant
Préparation du Sprint suivant:
- Présentation de l’objectif prévisionnel du Sprint.
- Liste des éléments prévisionnels du prochain Sprint
- Vérification du respect de la définition du Ready.
- S’assurer de la bonne granularité des éléments du Sprint à venir.
Travail sur le Release Plan et les Points de Blocage
La répartition des éléments dans les sprints:
- Revue de la répartition des éléments : après la revue de la Product Vision, une réestimation, un ajout ou une suppression d’élément, le scope prévisionnel des Sprints à venir doit être revu.
Les éléments bloqués:
- Identification des raisons de blocage (technique, architectural, organisationnel…)
- Définition d’un plan d’action : développement d’un POC (Proof Of Concept), intervention d’un expert
Recommandations
Spritn Review
- Évitez de planifier la revue durant les 20% de début ou de fin de Sprint.
Complexité
- Lorsque le projet est complexe (par exemple plusieurs équipes en parallèle), n’hésitez pas à faire des revues informelles ou des ateliers de travail en amont de la revue.
- Le Product Owner devrait de toute façon monter des ateliers de travail en interne côté client, pour affiner sa compréhension du besoin.
Priorisation
- Assurez-vous que tout le monde comprend que les priorisations et estimations effectuées durant la Product Backlog Review ne sont pas définitives : elles ne le seront que lors du Sprint Planning.
Contrôle
- Le Product Owner doit bien maîtriser les éléments du Product Backlog qu’il va présenter, il doit en connaître les détails. De même, les participants à la revue peuvent revoir le Product Backlog la veille.
Granularité
- N’hésitez pas à découper un élément durant la revue, elle sert à ça !
Anticipation
- Assurez-vous que le Product Owner a bien conscience qu’à chaque revue de Product Backlog, il doit présenter suffisamment d’éléments pour qu’il y ait du travail pour les 2 Sprints suivant le Sprint en cours.
- Ne centrez pas la revue du Product Backlog uniquement sur le Sprint N+1
- Autorisez-vous à regarder des éléments qui devraient être traités bien plus tard.
Suivi
- Chaque fois qu’il y a un risque ou un litige important sur un élément du Product Backlog, ne cherchez pas à le résoudre en séance, mais créez une action et suivez-la.
Conseil
- Ne pas oublier le rôle de conseil de l’équipe auprès du Product Owner que ce soit sur des aspects méthodologiques, techniques ou fonctionnels.
- Sur un projet d’intégration par exemple, l’Expert Technique et le Business Analyst doivent essayer de faire respecter le standard natif de la solution.
0 commentaires