Organiser efficacement son Product Backlog SCRUM
Voyons maintenant comment organiser le Product Backlog.
Comme on l'a vu précédemment, le Product Backlog est une sorte de réservoir dans lequel seront stockées les fonctionnalités souhaitées du produit.
Certaines fonctionnalités peuvent dépendantes les unes des autres et concerner de nombreux domaines différents.
Il est donc important de prendre soin de son organisation.
En SCRUM, il existe une hiérarchie dans les éléments du Product Backlog.
Tout d'abord, on peut citer les thèmes qui peuvent être vus comme des domaines fonctionnels.
Par exemple, pour le développement d'un site de e-commerce, on pourrait imaginer un thème lié au paiement.
Sous ces thèmes, on retrouvera les Epics.
Ce sont de grandes fonctionnalités générales qui vont regrouper plusieurs User Stories.
Ici, on pourrait, par exemple, avoir un Epic "En tant que client, je veux pouvoir voir et modifier ma commande afin de la vérifier avant de passer commande".
Cette demande est trop vaste pour être traitée en une seule User Story.
Sous les Epics, on retrouve bien sûr les User Stories, qui sont des fonctionnalités qui seront développées durant les sprints.
Une User Story peut se décrire comme une phrase simple, prise du point de vue de l'utilisateur.
Dans notre exemple, on pourrait imaginer : "En tant que client, je veux pouvoir consulter la liste de mes articles pour vérifier ma commande avant de procéder au paiement."
Sous les User Stories, on aura des taches, qui sont l'ensemble des étapes à réaliser afin de considérer une User Story comme terminée.
Ces taches sont définies lorsque l'équipe met en place des plans d'actions.
Il est même possible de découper les taches en sous-taches si c'est nécessaire.
Toutes ces terminologies ont pour but d'homogénéiser l'organisation et que tout le monde sache de quoi on parle.
En dehors de tout cela, d'autres éléments peuvent avoir leur place dans le Product Backlog.
On peut y retrouver les Spikes.
Parfois certaines User Stories méritent une analyse précise qui peut être une activité à part entière.
On appelle ces analyses Spikes et ont leur place dans le Product Backlog.
Ces analyses sont utiles pour clarifier certains points d'une User Story afin de pouvoir mieux l'estimer.
On peut décider des Spikes à ajouter au Product Backlog lors des Backlog refinement par exemple.
On peut aussi y présenter les résultats d'un Spike.
Les bugs
Le Product Backlog peut aussi accueillir les bugs.
Ce sont les problèmes rencontrés par les clients ou découverts par les membres de l'équipe, qu'il va falloir corriger.
Tous ces éléments seront stockés au même endroit, dans le Product Backlog et pourront être intégrés dans les sprints lors des sprint plannings.
D'une manière générale, on appelle Product Backlog Item ou PBI, tout élément qui a sa place dans le Product Backlog.
Ce regroupement permet plus de transparence au sein de l'équipe, car le Product Backlog étant visible par tous, tout le monde peut savoir où l'équipe en est et quelles sont ses difficultés.