Voir la source de Les qualités DEEP d'un Backlog Produit

[[Category: Portail Product Owner]]
[[Catégorie:Backlog DEEP]]
Auteur : Amit Sinha<br/>
Source : [https://agilonomics.com/the-deep-qualities-of-a-product-backlog/ The DEEP Qualities of a Product Backlog]<br/>
Date : 26/07/2021<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 05/12/2023<br/>
----
Traduction :<br/>
<br/>
[[Fichier:Aligned-With-The-Big-Picture.png|border|link=]]<br/>
<br/>
Artéfact le plus populaire et le plus important de Scrum, le [https://agilonomics.com/the-deep-qualities-of-a-product-backlog/ backlog produit] n'est jamais complet. Il évolue constamment, au fur et à mesure que [https://agilonomics.com/the-problem-with-requirement-specification-documents/ les exigences ou l'environnement d'un projet] évoluent et changent. Il est simple mais utile, s'il est utilisé à bon escient. Il répertorie toutes les caractéristiques, les fonctions, les exigences, l'environnement, les défauts à corriger et bien d'autres choses encore. En d'autres termes, il s'agit d'une liste priorisée du travail restant à accomplir pour donner vie au produit.<br/>
<br/>
[[Fichier:Most-Popular-Artifact.png|border|link=]]<br/>
<br/>
Un backlog produit opérationnel possède quatre qualités principales : une description, une estimation, un ordre et une mise à jour constante, ce qui permet de s'assurer que les détails sont toujours alignés sur la vue d'ensemble. Ceci est exprimé par l'abréviation DEEP* - Detailed Appropriately, Estimated, Emergent and Prioritized (Détaillé de manière appropriée, Estimé, Émergent et Priorisé).<br/>
<br/>
[[Fichier:DEEP-acronym.png|border|link=]]<br/>
(*)L'acronyme DEEP a été inventé par Mike Cohn et Roman Pichler.<br/>

==Détaillé de manière appropriée==
Les éléments du backlog de produits sont détaillés de manière à ce que les éléments les plus prioritaires soient plus granulaires et plus détaillés que les éléments moins prioritaires. Plus la priorité est faible, moins l'élément est détaillé.<br/>
<br/>
[[Fichier:D-Detailed-Appropriately.png|border|link=]]<br/>

==Estimé==
Les éléments du backlog produit sont estimés. Les estimations ne sont pas définitives et sont souvent exprimées en [https://agilonomics.com/jobs-to-be-done-vs-user-story-maps-1/ story] points ou en jours idéaux (le nombre de jours d'efforts qu'il faudrait pour terminer une story si l'équipe travaillait sans interruption).  Connaître la taille des éléments permet d'établir des priorités et de planifier la livraison. Bien que les éléments moins prioritaires aient des estimations moins précises que les éléments plus prioritaires situés en haut du backlog, ils doivent tous avoir une estimation approximative.<br/>
<br/>
[[Fichier:E-Estimated.png|border|link=]]<br/>

==Émergent==
Le backlog produit est organique ; il évolue constamment, changeant fréquemment au fur et à mesure que de nouveaux éléments sont découverts et ajoutés sur la base du feedback des utilisateurs et des clients. Les éléments existants sont repriorisés, modifiés, affinés ou supprimés - continuellement.<br/>
<br/>
[[Fichier:E-Emergent.png|border|link=]]<br/>

==Priorisé==
Les éléments du backlog produit sont priorisés. Les éléments les plus importants et les plus prioritaires sont réalisés en premier. Ils se trouvent en haut du backlog. Une fois qu'un élément est terminé, il peut être retiré du backlog. Les éléments moins prioritaires, qui peuvent être envisagés plus tard, se trouvent au bas du backlog produit. Les [https://agilonomics.com/a-meaningful-dashboard-for-agile-teams/ équipes] terminent toujours les éléments les plus prioritaires en premier afin de s'assurer que la valeur du produit est maximisée.<br/>
<br/>
[[Fichier:P-Prioritized.png|border|link=]]<br/>
<br/>
Bien que l'ensemble de I'[https://agilonomics.com/an-ideal-career-path-for-a-scrum-master/ Équipe Scrum] collabore et contribue à l'affinage, le maintien d'un backlog produit relève de la responsabilité du [https://agilonomics.com/product-owner-or-business-analyst/ Product Owner]. 10% de la disponibilité et de la capacité de de l'Équipe Scrum sont alloués à l'affinage. L'affinage étant un processus continu au cours du sprint, le Product Owner met à jour et affine en permanence le backlog produit. S'assurer que le backlog produit est DEEP grâce à des sessions d'affinage régulières permet de s'assurer que le backlog produit ne devient pas un trou noir d'éléments, de fonctionnalités et de stories redondants, inutiles et superflus. Un backlog bien entretenu et DEEP vous aidera à réussir dans le cadre de l'approche Agile.<br/>
<br/>
[[Fichier:Fine-Level-Backlog.png|border|link=]]