Recueillir efficacement les besoins
CHAPITRE 3
103
Les composants de cette liste sont les product backlog items (PBI), des descriptions de
haut niveau des fonctionnalités, qui s’affineront au fur et à mesure de l’avancement du
projet ; ce peut être des user stories, des cas d’utilisation…
Les PBI sont hiérarchisés dans le product backlog par le client en fonction de leur valeur
ajoutée. Le PB est donc un référentiel évolutif, élaboré avec une démarche de recueil
dynamique, d’une part parce qu’au fil du projet, de nouvelles user stories peuvent être
ajoutées et d’autres reportées, annulées, subdivisées, d’autre part parce qu’il recense
également les demandes de changements, défauts, évolutions qui viennent, en cours de
route, alimenter la liste des travaux à réaliser.
Les PBI qui ne seront traités qu’ultérieurement peuvent rester à l’état macroscopique,
l’équipe se focalisant sur les plus prioritaires. Cela laisse au client la possibilité de
décider, le plus tard possible, de l’implémentation de telle ou telle story, en fonction
de ses priorités et des informations plus récentes dont il disposera ; cela offre à
l’équipe de réalisation l’avantage de livrer un produit qui « colle » au plus près aux
priorités.
Le PB est sous la responsabilité du seul représentant du client, le product owner (Scrum),
qui agit comme véritable interface de communication entre l’équipe et le client.
Cas pratique
Reprenons notre exemple décrit plus haut au paragraphe « Partager une vision » : nous avons vu
comment la vision pouvait se décliner en exigences fonctionnelles et non fonctionnelles ; voyons
maintenant (figure 3-9) comment elle peut se décliner en user stories.
Figure 3-9
Exemple de product backlog (extrait)
Dans notre exemple, on distingue les PBI qui sont prioritaires (dans la partie supérieure du
tableau) de ceux qui seront traités ultérieurement (dans la partie inférieure).
Niveau 1 de granularité
Niveau 2 de granularité
Priorité
Risque Valeur Effort
UC-01: Renseigner les caractéristiques produit
Indexer une portion de document source
M
1
1
Enrichir le thésaurus avec un nouveau terme d'indexation
S
2
2
Associer une remarque éditoriale à une fiche produit
C
3
2
Optimisation des temps de recherche
S
1
3
UC-02: Renseigner les données économiques
Saisir le prix public avec sa date d'effet
M
2
3
Indiquer une date de commercialisation pour le produit
M
3
3
Masquage / affichage des champs en fonction du type
de produit
C
2
2
Refonte de la mise en page
W
1
1
Bureau métier
Interface de connexion des composants applicatifs
M
2
1
Intégration "to do list"
S
3
3
Gestion de l'authentification
C
3
2
UC-03: Produire les annexes
M
2
1
UC-04: Gérer les publications
M
2
2
UC-05: Produire les tableaux de bord
S
3
2
Stories de
haut niveau,
moins
analysées
Stories
affinées,
mieux
analysées
Product Backlog (extrait)
GestProjInform Livre Page 103 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 3
103
Les composants de cette liste sont les product backlog items (PBI), des descriptions de
haut niveau des fonctionnalités, qui s’affineront au fur et à mesure de l’avancement du
projet ; ce peut être des user stories, des cas d’utilisation…
Les PBI sont hiérarchisés dans le product backlog par le client en fonction de leur valeur
ajoutée. Le PB est donc un référentiel évolutif, élaboré avec une démarche de recueil
dynamique, d’une part parce qu’au fil du projet, de nouvelles user stories peuvent être
ajoutées et d’autres reportées, annulées, subdivisées, d’autre part parce qu’il recense
également les demandes de changements, défauts, évolutions qui viennent, en cours de
route, alimenter la liste des travaux à réaliser.
Les PBI qui ne seront traités qu’ultérieurement peuvent rester à l’état macroscopique,
l’équipe se focalisant sur les plus prioritaires. Cela laisse au client la possibilité de
décider, le plus tard possible, de l’implémentation de telle ou telle story, en fonction
de ses priorités et des informations plus récentes dont il disposera ; cela offre à
l’équipe de réalisation l’avantage de livrer un produit qui « colle » au plus près aux
priorités.
Le PB est sous la responsabilité du seul représentant du client, le product owner (Scrum),
qui agit comme véritable interface de communication entre l’équipe et le client.
Cas pratique
Reprenons notre exemple décrit plus haut au paragraphe « Partager une vision » : nous avons vu
comment la vision pouvait se décliner en exigences fonctionnelles et non fonctionnelles ; voyons
maintenant (figure 3-9) comment elle peut se décliner en user stories.
Figure 3-9
Exemple de product backlog (extrait)
Dans notre exemple, on distingue les PBI qui sont prioritaires (dans la partie supérieure du
tableau) de ceux qui seront traités ultérieurement (dans la partie inférieure).
Niveau 1 de granularité
Niveau 2 de granularité
Priorité
Risque Valeur Effort
UC-01: Renseigner les caractéristiques produit
Indexer une portion de document source
M
1
1
Enrichir le thésaurus avec un nouveau terme d'indexation
S
2
2
Associer une remarque éditoriale à une fiche produit
C
3
2
Optimisation des temps de recherche
S
1
3
UC-02: Renseigner les données économiques
Saisir le prix public avec sa date d'effet
M
2
3
Indiquer une date de commercialisation pour le produit
M
3
3
Masquage / affichage des champs en fonction du type
de produit
C
2
2
Refonte de la mise en page
W
1
1
Bureau métier
Interface de connexion des composants applicatifs
M
2
1
Intégration "to do list"
S
3
3
Gestion de l'authentification
C
3
2
UC-03: Produire les annexes
M
2
1
UC-04: Gérer les publications
M
2
2
UC-05: Produire les tableaux de bord
S
3
2
Stories de
haut niveau,
moins
analysées
Stories
affinées,
mieux
analysées
Product Backlog (extrait)
GestProjInform Livre Page 103 Vendredi, 3. avril 2009 12:07 12