1. Gestion de projet informatique
2. Méthodes
3. Le backlog produit en Scrum

Le backlog produit en Scrum

Ce qui fait un bon manager c'est la prise de décision. On peut utiliser les ordinateurs les plus fous pour étudier les chiffres mais en final il faudra faire un planning et passer à l'action.

– Lee Lacocca

Tout dans Scrum tourne autour du backlog produit. Ce backlog contient, sous forme de liste, les choses que le client veut que l'équipe réalise. C'est en quelque sorte une « liste priorisée d'exigences, d'histoires, de caractéristiques, ou autre ». Le backlog produit est maintenu par le product owner.

De quoi est fait un backlog produit ?

Les éléments du backlog sont appelées de histoires (user stories). Une histoire doit avoir un but métier, son ajout au backlog doit généralement justifier une valeur ajoutée, une « business value ». On n'y met pas de tâches techniques du genre « Réécrire l'algo d'import de produits en C », mais plutôt des item faisant sens au niveau métier « Augmenter la rapidité de l'import des produits » : le fait de l'implémenter en C plutôt qu'un Cobol objet (!) appartient à l'équipe technique, et ce n'est pas au product owner ou au client de le décider (ce n'est pas de sa responsabilité : s'il le fait, c'est généralement considéré comme de l'ingérence vis-à-vis de l'équipe technique).

Comment écrire une user story ?

Au sein du backlog, chaque user story constitue un item, une ligne : le backlog produit se présente comme un tableau ordonné par priorité. Pour chaque histoire, on décrit généralement dans le backlog :

• Un identifiant unique, que l'on incrémente à chaque nouvelle histoire, comme une clé primaire auto-incrémentée dans une BDD. Cet identifiant permet de garder la trace des histoire même quand on les renomme (ce qui arrive très souvent).
• Un nom de quelques mots décrivant l'histoire. Généralement, pour rendre ce nom explicite, une bonne façon de procéder est d'utiliser le template suivant : « En tant que X, je veux Y, afin de Z ». Exemple : « En tant que responsable commercial, je veux mettre en place un outil d'upload massif des prix, afin d'optimiser les temps de modification des prix dans mon équipe ». Le product owner ne doit jamais oublier que la spécification d'un besoin est juste un problème de communication : ceux qui ont un besoin doivent communiquer avec ceux qui peuvent le réaliser, et la première chose à faire est d'exprimer clairement et très simplement ce que l'on veut.
• Une description de la story.
• L'importance de la story. C'est un nombre qu'attribue le product owner à l'histoire : plus l'importance est grande, plus l'histoire devra être traitée en priorité. On évite de parler directement de priorité car c'est peu pratique (notamment pour modifier ensuite les prios). Astuce : choisissez des nombres qui ne se suivent pas, ce sera plus simple par la suite pour y intercaler des choses (ex. : c'est facile d'intercaler une story d'importance 45 entre deux stories d'importances 50 et 40).
• L'estimation initiale de l'équipe pour cette histoire. Généralement cette case est vide au moment où le product owner insère l'histoire dans le backlog : elle est complétée par la suite durant le round d'estimation avec l'équipe. Nous en reparlerons plus bas.
• Le « how to demo », qui indique comment l'équipe montrera, lors de la démonstration de la fonctionnalité, que ça marche. Exemple : « Authentification, ouverture du module de stock, ajout de 3 quantités pour un produit, ouverture de la page de visualisation des stocks et vérification que la modification a été prise en compte ».
• Demandeur : si vous avez plusieurs clients, c'est intéressant de conserver le nom de celui qui a émis la demande.

Ca y'est, vous avez votre backlog !