Tous les éléments du backlog de produit n’auront pas la même taille et le même niveau de détail en même temps (c’est-à-dire les fonctionnalités/eprics/user stories et tâches). Les PBI sur lesquels nous prévoyons de travailler prochainement devraient être proches du haut du backlog, de petite taille et très détaillés afin qu’ils puissent être travaillés dans un sprint à court terme. Les PBI sur lesquels nous ne travaillerons pas avant un certain temps devraient être vers le bas du backlog, de plus grande taille et moins détaillés.
Les cas d’utilisation/fonctionnalités sont des capacités que vos utilisateurs finaux auront et qu’ils n’avaient pas auparavant. Par exemple, l’achat d’articles en ligne via votre téléphone mobile serait une fonctionnalité. La feuille de route de votre produit se compose généralement d’exigences au niveau des fonctionnalités.
Les épopées sont la prochaine étape dans la décomposition d’une fonctionnalité en une exigence actionnable. Il s’agit d’une série d’actions liées à la fonctionnalité. La possibilité d’acheter un article via votre téléphone portable à partir du panier en utilisant une carte de crédit serait une épopée. C’est plus petit qu’une fonctionnalité (acheter un article en ligne), mais c’est pourtant plus grand que les intégrations de cartes de crédit individuelles qui permettent individuellement d’acheter un article. Nous n’autorisons pas les exigences supérieures aux épopées dans un plan de publication.
Les user stories sont les plus petites formes d’exigences qui peuvent encore se suffire à elles-mêmes. Une user story consiste en une action de valeur ou une intégration de valeur. Par exemple, l’achat d’un article via votre téléphone portable à partir du panier d’achat à l’aide d’une carte Visa serait une histoire d’utilisateur. L’achat d’un article à l’aide d’une MasterCard pourrait être une intégration différente et donc une histoire d’utilisateur différente. Les user stories sont suffisamment petites pour être ajoutées aux sprints et commencer à se développer. J’entre dans les histoires d’utilisateurs en détail dans les sections qui suivent.
Les tâches sont les étapes internes nécessaires à la mise en œuvre de la user story. Lors de la planification de sprint, une user story est décomposée en tâches. Alors que les exigences sont des choses que l’utilisateur final fait, les tâches sont ce que l’équipe de développement fait pour que l’exigence fonctionne.
Niveau de granularité des éléments du backlog produit (PBI)
La figure illustre les différentes couches de décomposition des exigences pour s’adapter à une série de sprints de la feuille de route de développement
- En haut de cette figure ci-dessus se trouvent les briques orange les plus grandes. Ils représentent les objectifs commerciaux à atteindre par le système, à savoir les cas d’utilisation ou les fonctionnalités utilisateur.
- Au niveau inférieur se trouvent les PBI qui sont plus grands qu’un seul sprint mais plus petits qu’une version. Appelons le PBI à ce niveau des épopées.
- Au troisième niveau, nous trouvons des PBI qui sont dimensionnés de manière appropriée pour un sprint – ils peuvent être complétés en jours plutôt qu’en semaines. Ces éléments répondent à la définition de Ready de l’équipe et peuvent être représentés sous forme de user stories.
- Au niveau le plus bas, ces PBI peuvent éventuellement être décomposés en tâches à partir d’une user story et livrés à la fin d’une seule itération.
Carnet de produit
Le Product Backlog répertorie tous les livrables requis. Son contenu est classé par valeur métier. Comme mentionné ci-dessus, les éléments les plus importants sont affichés en haut du carnet de produit afin que l’équipe sache quoi livrer en premier. La priorité des éléments du backlog peut changer, des exigences peuvent être ajoutées et supprimées. Ainsi, le backlog du produit est un plan maintenu en permanence vers une valeur commerciale croissante.
Éléments du carnet de produit
Les Product Backlog Items (PBIs) sont les éléments qui composent le Product Backlog. Les éléments du backlog de produit peuvent aller des spécifications et des exigences aux cas d’utilisation, aux épopées, aux histoires d’utilisateurs, voire même aux bogues, ou aux tâches de recherche limitées dans le temps.
Processus de planification de sprint
La planification de sprint est souvent nécessaire pour se préparer à s’assurer que le backlog de produit a été affiné à un niveau de détail approprié, avec des estimations et des critères d’acceptation (c’est le but de l’affinement du backlog de produit). Si les éléments du backlog produit ont été analysés et réfléchis au cours du processus de raffinement du backlog produit, lors de la réunion de planification de sprint, les éléments prioritaires du backlog produit peuvent être bien compris et facilement sélectionnés.
Sommaire
L’objectif du processus d’affinement du backlog produit est d’obtenir des éléments du backlog produit dans un état prêt pour la planification du sprint, de sorte que les éléments du backlog produit soient :
- Assez clair et compréhensible par tous les membres de l’équipe
- Assez petit pour être inclus dans un sprint
Français
English
简体中文
繁體中文
Deutsch
Español
العربية
Italiano
Português
日本語
Nederlands
Русский