Scrum: Le Backlog de produit
Le Backlog de sprint, Quésaco?
A la base de tout projet mettant en œuvre la méthode Scrum, il y a la création du backlog de produit.
Le backlog de produit est le document cadre qui servira à la planification de tout le projet et qui servira de référence fonctionnelle sur les exigences du client.
Il se présente sous la forme d’une liste priorisée d’exigences, d’histoires et de caractéristiques décrites par le client. Ce document sera rédigé par le client, en la personne du Directeur de produit puis présenté et completé avec toute l’équipe de développement notamment pour l’estimation du temps..
Ce document, qui peut se présenter sous la forme d’un fichier Excel accessible mis à disposition de l’équipe sur le portail Sharepoint du projet ou dans un dossier partagé.
Structure du backlog
Le backlog comprend les champs de base suivants:
- Le champ Importance, qui définit comme son nom l’indique l’importance contractuelle de la réalisation de cette partie du projet.
- Le champ ID qui détermine un identifiant unique pour l’histoire en question.
- Le champ Nom, ou Description qui décris de manière claire et succincte la fonctionnalité désirée par le client
- Le champ Estimation qui estime en « points » la charge de travail. (L’unité de point fixée au début du projet correspond à des « Jours/Homme idéaux »: 1 point = 1 jour/homme idéal)
- Le champ Comment démontrer qui fait office de spécification de test ultra simplifiée (1 à 2 phrases succinctes).
- Le champ Notes qui permet d’ajouter toute information complémentaire indispensable à la bonne compréhension de l’histoire.
backlog de produit
Bien sûr chaque projet est différent et ce tableau doit pouvoir s’adapter au contexte, à l’organisation, et à toute sortes de paramètres qui peuvent être important de préciser dans le backlog. C’est pourquoi vous êtes libres d’ajouter à ces champs d’autres champs que vous pourrez juger utiles tels que:
- Un champ Catégorie qui fera la distinction entre les nouveau développements et les optimisations par exemple.
- Un champ ID de suivi de bug si vous utilisez un système de suivi de bug.
On peut donner de nombreux exemple, et c’est à vous de juger si la nécessité de tel ou tel champs se justifie. N’oubliez pas cependant que ce document n’as qu’un rôle de cadre et qu’il ne doit en aucun cas être surchargé afin de rester lisible.
L’Importance
Le champs importance est déterminé selon une échelle totalement libre. En effet une histoire avec une importance à 80 ne seras pas forcément 4 fois plus importante qu’une histoire avec une importance de 20.
Simplement, il est important que chaque histoire ait une importance unique afin de créer une hiérarchie claire entre celles-ci et il est également important de laisser un écart suffisant entre chacune d’elle à la création du backlog. Il faudra être en mesure de pouvoir insérer de nouvelles histoires que l’on aurait pas forcément prévu.
Pour aider à déterminée l’échelle que l’on va utiliser, on peut se fixer 3 seuils avec un code couleur:
- >= 50: (Rouge) Histoire indispensable à la release. Si elle ne sont pas livrées à temps, cela entraînera des pénalités.
- 20 < x < 50: (Jaune) Histoire indispensable mais qui autorise un petit délai de livraison sans pénalité.
- <= 20: (Vert) Histoire secondaire qui pourront être livrées dans une version mineure suivante.
Une fois ceci effectué, on complètera le backlog avec le code couleur choisit pour une meilleur lisibilité du document.
backlog de produit avec code couleur
A retenir
Garder bien en tête que le Directeur de produit doit rester focalisé sur les objectifs métier et ne pas se soucier des aspects techniques. C’est également le cas pour ce document qu’il rédige et qui ne servira que de cadre fonctionnel à l’équipe.
Commentaires