by Identifier les PBIs (Product Backlog Items)
- Le Product Backlog représente tout le travail à faire pour créer le Produit, tout le travail tel que celui-ci est connu à un moment donné.
- Il va donc y avoir plusieurs versions du Product Backlog, celui-ci va évoluer de Sprint en Sprint au fur et à mesure que les informations arrivent et que nous tenons compte à la fois du résultat des Sprints, de nos apprentissages, des demandes de changement et des feedbacks des Parties Prenantes lors de chaque Sprint Review.
- Le Product Backlog est constitué du Product Goal et de Product Backlogs Items plus ou moins finement décomposés et décrits.
- Ces Product Backlog Items peut être écrit et décrits de diverses façons à la convenance de la Scrum Team.
- Pour rappel, la Scrum Team est contituée par les 3 responsabilités : le Product Owner (PO), les Developers (ou Membres de l’Equipe, Team Members, TMs) et le Scrum Master (SM).
Trier, organiser et prioriser
- Le Product Owner (PO) a la responsabilité de la priorisation du Product Backlog, il peut bien sûr se faire assister de son équipe (Scrum Team mais il a le dernier mot quant à la priorisation.
- Cas particulier de l’agilité à l’échelle (Scaling Agile)
- Puisqu’il n’y a qu’un seul Produit, il n’y a qu’un seul Product Owner (PO) même si plusieurs équipes travaillent sur la réalisation du même Produit et coordonnent leurs efforts.
- Il peut prendre dans ce cas-là le nom de Senior Product Owner (SPO), Product Manager (PM) suivant les frameworks utilisés, par opposition au Product Owner (PO) qui intervient au niveau de chaque Scrum Team, et qui fait partie de chaque Scrum Team.
- Notons qu’au niveau des équipes, un même Product Owner (PO) peut intervenir pour une plusieurs équipes (Scrum Teams) en fonction de leur maturité et de leur connaissance du Produit à réaliser.
- Pour en connaître davantage, voir les frameworks Nexus, Scrum of Scrum, SAFe, Disciplined Agile (DA) et autres frameworks d’agilité à l’échelle.
- Puisqu’il n’y a qu’un seul Produit, il n’y a qu’un seul Product Owner (PO) même si plusieurs équipes travaillent sur la réalisation du même Produit et coordonnent leurs efforts.
Comment prioriser ?
- En utilisant la technique MoSCoW
- M : Must have
- Le “Must have” représente les PBIs, élements ou fonctionnalités essentielles au bon fonctionnement du Produit :
- MVP : le Must have permet d’identifier ce qui va constituer le M.V.P (voir Agile terminology).
- Noyau : le MVP ou Noyau du Produit sera livré lors de la première Release
- La raison d’être de cette première Release (livraison du MVP) aura un rôle d’apprentissage
- Elle nous permettra de vérifier ou d’infirmer nos hypothèses de travail et de décider de poursuivre, de modifier notre approche voire même d’arrêter (approche Lean Startup).
- Le “Must have” représente les PBIs, élements ou fonctionnalités essentielles au bon fonctionnement du Produit :
- S : Should have
- Le “Should have” permet d’identifier les PBIs, à pluguer sur le noyau (MVP) :
- Ceux-ci seront en général livrés lors de la deuxième Release
- Le “Should have” permet d’identifier les PBIs, à pluguer sur le noyau (MVP) :
- C : Could have
- Le “Could Have” permet d’identier des PBIs, éléments de confort :
- Ceux-ci seront livrés en dernière Release
- Le “Could Have” permet d’identier des PBIs, éléments de confort :
- W : Won’t have this time
- Le “Won’t have this time” permet d’identifier d’autres PBIs qui ne font pas partie actuellement du contenu de notre Produit, ils sont hors périmètre.
- Néammoins ces Items peuvent en cours de projet suite à des demandes de changement être incorporés à notre Product Backlog.
- Le “Won’t have this time” permet d’identifier d’autres PBIs qui ne font pas partie actuellement du contenu de notre Produit, ils sont hors périmètre.
- M : Must have
Priorisation ?
- Comment effectuer la priorisation ?
- En fonction de la Valeur (Value)
- En fonction du niveau de Risques (Risk, opportunités et menaces)
- En fonction du coût de développement (Development Cost) et de la durée (Time), c’est à dire l’effort
- En fonction du côté “mandatory” pour certains PBIs techniques (Tech Stories, NFR)
- Et d’autres …
Estimations ?
- Comment estimer les PBIs ?
- Valeur (Value) ?
- Complexité (Complexity) ?
- Risques, niveau de risques (Risk) ?
- Obligatoires (Mandatory) ou non ?
- Priorité (Priority) ?
- Comment faire ces estimations ?
- A l’aide des estimations collectives, participatives et collaboratives (Planning Poker)
Concernant les responsabilités du Product Owner (PO), voir aussi :
- Le framework Agile Discipliné (Disciplined Agile – DA)
- The Scrum framework
- Agile and quality
- Scrum with Kanban
- Scrum and practices
- Agile and quality
- Scrum and practices
Versions
- Créé le 01/01/2023.
- Mis à jour : 16/01/2023.
