Backlog exemple

product backlog
product backlog

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.

Backlog – définition

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 :

story mapping priorisé
story mapping priorisé – backlog exemple

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.

[ Article lu 8 fois aujourd'hui ]
A propos Judicaël Paquet 629 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.