Toutes les User Stories du "Product Backlog" passent par un cycle de vie connu depuis son intégration initiale comme idée ou Bouillant, jusqu'à la mise de cette fonctionnalité dans les mains de l'utilisateur final (Mise en Production), sachant que le "Product Owner" doit être capable de bien gérer son backlog et suivre les différentes User Stories qui le composent (Affinage, réalisation).
Pour mieux gérer son Product Backlog, le product owner peut faire appel à l'un des Patterns les plus fréquemment pratiqués, on parle bien évidement du "Pattern des Bacs", qui consiste à bien ranger et organiser les différentes User Stories existantes dans des cases appelées bacs selon l'état de chaque fonctionnalité (Idée ou Brouillant, Affinage, Ready pour Développement, en réalisation, et DONE).
Toute Demande ou User Story va intégrer le Backlog initialement sous forme d'une idée ou un brouillant suite à un premier échange entre le Product Owner et les parties prenantes, donc pour commencer, on peut mettre ces User Stories partageant cet état dans un bac initial appelé "Bac à Sable". Sachant que ce bac peut contenir autre types de demandes en occurrence les "Technical Requirement" demandées par les développeurs (dédiées à corriger la dette technique, développer des composants techniques réutilisables, ...Etc.).
Selon l'ordre de priorité des demandes, le Product Owner peut intervenir pour détailler et affiner certaines idées pour les rendre sous le format d'une User Story, du coup leur état va changer et elles vont passer dans ce cas de figure à un deuxième bac appelé "Bac d'Affinage" ou bien "Bac de Culture".
Une fois les User Stories deviennent matures, affinées et prêtes pour être réalisées, le Product Owner peut les embarquer dans des Sprints selon la criticité et l'ordre de priorité dans le Product Backlog, alors pour cela toutes les demandes ayant cet état vont être déplacées dans un troisième bac appelé "Bac de Départ", qu'on peut aussi nommé "Bac d'attente" vu qu'il y aura pas d'évolution sur ces demandes sauf en cas de changement du besoin déclaré par les parties prenantes ou le déclencheur initial de ces fonctionnalités.
Une fois développées, les User Stories qui sprintent durant les Sprints vont changer d'état en devenant prêtes et en statut "DONE" au fil de l'eau, alors il faut les déplacer dans ce cas de figure vers un autre bac qui s'appelle le "Bac d'arrivée", ou "Bac Final" en attendant leurs démonstrations durant le rituel du "Sprint Review", si tout passe bien alors ils vont être mises en production, sinon il y'aura des corrections ou rectifications à faire par l'équipe de développement.
Une fois les User Stories finies sont dans les mains des utilisateurs finaux, alors on peut dans ce cas de figure vider le bac d'arrivées, et on considère que leur cycle de vie est achevé.
Pour les demandes bloquées, suspendues temporellement, ou qui sont en attente d'une décision stratégique, on peut les mettre dans un bac spécial nommé "Bac à Glace", et une fois la situation est débloquée, alors on peut les mettre dans leurs bacs précédents.
Les Product Owner peuvent utiliser ce Pattern pour mieux gérer leurs Backlog car il porte plusieurs avantages, en occurrence :
Avoir un schéma lisible, clair, bien structuré, et bien organisé pour les différentes demandes du Product Backlog.
Avoir la possibilité d'établir un planning à cours et moyen terme permettant d'identifier le moment de passage des demandes d'un bac à l'autre.
Respecter la capacité de l'équipe de développement lors de l'embarquement des User Stories dans les Sprints.
Bien Gérer le planning des mises en production / Releases.
Déterminer les moments idéaux pour planifier les séances d'affinage que ça soit avec les parties prenantes ou les développeurs.
Conclusion :
Parmi les tâches principales d'un Product Owner, c'est la gestion et le suivi du Product Backlog, alors le Pattern Bac sera un moyen et une pratique efficace pour ce travail, bien sûr en étroite collaboration avec les autres acteurs (Utilisateurs finaux, Parties Prenantes, et l'équipe de développement).
Le "Pattern des Bacs" ne concerne pas que les demandes fonctionnelles dites User Stories, mais plutôt l'ensemble des types des demandes qu'on peut trouver dans un Product Backlog. Vous pouvez lire l'article du "Pattern Storyotype" traité dans un de mes articles publiés dans mon blog.
Comments