Rendre le Product Backlog DEEP
Auteur : Mike Cohn
Source : Make the Product Backlog DEEP
Date : 14/12/2009
Traducteur : Fabrice Aimetti
Date : 18/12/2009
Traduction :
Roman Pichler, auteur de "Agile Product Management with Scrum: Creating Products that Customers Love", et moi utilisons l'acronyme DEEP pour résumer les principales propriétés d'un bon Backlog Produit.
- Détaillé de façon appropriée : les user stories du Backlog Produit qui sont sur le point d'être réalisées doivent être suffisamment bien comprises pour être terminées dans le sprint à venir. Les stories qui ne seront pas développées à court terme peuvent être décrites avec moins de détails.
- Estimé : le Backlog Produit représente plus qu'une liste de tout le travail à effectuer ; c'est aussi un outil de planification utile. Les items en bas du Backlog Produit n'étant pas (encore) bien compris, les estimations associées seront donc moins précises que les estimations fournies pour les items en haut du Backlog Produit.
- Évolutif / Émergent : un Backlog Produit n'est pas statique. Il va changer avec le temps. Au fur et à mesure, des user stories seront ajoutées, supprimées ou repriorisées dans le Backlog Produit.
- Priorisé : le Backlog Produit doit être trié avec les items de plus grande valeur en haut et ceux de moins grande valeur en bas. En respectant toujours l'ordre des priorités, l'équipe est en mesure de maximiser la valeur du produit ou système en cours de développement.
Les Backlog Produit sont abordés plus en détail dans "Succeeding with Agile: Software Development using Scrum".
