Cet article a pour but de vous montrer un exemple possible de backlog à constituer : backlog exemple. Il n’est pas toujours simple de constituer un backlog surtout la première fois. Je vais donc vous donner quelques pistes pour bien démarrer.
Vous pouvez regarder la vidéo de la minute agile sur le backlog :
Backlog exemple
Commençons par la définition du backlog
Voici la définition du backlog (aussi appelé product backlog) que j’avais donné sur ce blog :
Le product backlog est l’ensemble des besoins recueillis pour créer le produit désiré. Si on pense tout de suite aux user-stories, cela peut concerner également les items techniques, les spike voire les bugs.
Comme nous sommes en méthodes agiles, il faut comprendre que le scope du product backlog est variable ; en effet, nous pourrons y voir des éléments y apparaitre et d’autres disparaitre tout au long des développements du produit.
Vous pouvez regarder la vidéo de la minute agile sur le sujet du backlog produit :
Comment créer son premier backlog ?
Pour commencer à créer un backlog, l’exercice du story-mapping est vraiment excellent. Il permet de constituer une première vision d’un backlog sans les détails.
Vous pouvez aller voir notre article complet qui explique comment réaliser l’atelier du story mapping : Story mapping advanced
Et si vous n’aimez pas lire, vous pouvez également consulter notre vidéo complète qui explique comment réaliser ce story mapping :
Pour les pros : le framing agile (framework de cadrage de projet 100% agile) propose d’ailleurs un enchainement logique dans la phase « vision ». N’hésitez pas à consulter son déroulé : la vision du produit.
Donc voici le résultat d’un story mapping réalisé sur un site e-commerce classique :
A partir de cette image, nous pourrons donc un backlog contenant 3 étages différents : Thèmes / Epics (ou) features / items
Les items en jaune sont les fonctionnalités qui elles sont en rouge découpées en éléments encore plus petit. Ces éléments ne sont pas définitif et pourront changer à l’avenir.
La clé d’un backlog, c’est son évolution constante
Un backlog est un ensemble d’éléments qui vivent :
- des items vont disparaitre
- des items vont évoluer
- des items vont être créés
Contrairement à un cahier des charges, les éléments du backlog sont en constantes évolutions. Il ne faut pas tout écrire à l’avance mais se laisser une véritable capacité de le voir évoluer en temps réel (selon les besoins).
Donc pour faire simple, un backlog ne se termine jamais?
Ecriture des spécifications en juste à temps
Chaque item sera lié à un petit besoin à réaliser qui demandera d’être spécifié. Exemple de notre précédente image : « noter le produit ».
Le product owner fera son possible pour que les spécifications qui complète ce besoin soient écrites juste avant les développements. Et il y a plusieurs raisons pour cela :
- écriture des spécifications à jour par rapport aux découvertes que peut amener l’avancement du produit
- éviter que des découvertes que peut amener l’avancement du produit ajoute une obsolescence à la spécification (surtout quand elle est écrit 6 mois avant)
- éviter tout travail inutile : si l’item venait à ne jamais être réalisé
C’est une gymnastique peu évidente au début mais qui permet d’optimiser l’avancement du produit.
Un product owner qui découvre le métier pourra d’ailleurs utiliser des formats simples mais structurés de user-stories comme le story A4.
Story A4 : format de user-story très efficace
Ainsi seuls les items du prochain sprint seront totalement spécifiés et les autres resteront à l’étape d’un simple titre.
Cependant, si il est nécessaire d’avoir une roadmap (agile bien évidemment), il est toujours possible de faire une estimation en masse des user-stories :
Estimons avec de l’Extreme Quotation
Conclusion backlog exemple
J’espère que cet article vous aura éclairez sur le backlog et l’exemple de comment le constituer. Il n’est pas toujours simple de savoir par où commencer, surtout quand on découvre le métier de product owner.
Soyez le premier à commenter