Backlog : qu’est-ce que le backlog ?
Un backlog est une notion que l’on retrouve souvent dans l’actualité, mais qui peut toutefois sembler très complexe à appréhender. Définition, différences avec un cahier des charges, méthodes de gestion et importance de la priorisation, nous vous donnons toutes les clés d’un backlog efficace.
Qu’est-ce que le backlog ? Définition
Un backlog peut se définir de manière très simple. Il s’agit d’une liste qui priorise les fonctionnalités devant être améliorées ou développées, relativement à un produit ou un service.
Terme anglais pouvant être traduit en Français par “arriéré”, le backlog est une liste de tâches pouvant être assignées à un projet.
Plus précisément, un backlog fait directement référence à la méthode Scrum aussi appelée méthode agile. Le backlog Scrum constitue un véritable outil permettant de recueillir l’ensemble des besoins du client. Ces informations sont ensuite exploitées afin de mener à bien le projet donné. De ce fait, la liste de fonctionnalités contenues dans le backlog produit se révèle particulièrement utile à la conception d’un produit.
Ces fonctionnalités peuvent revêtir différentes formes, telles que de la “user story”, un brief, un gherkin, ou encore une maquette powerpoint.
Au-delà de ces informations sur les fonctionnalités, le backlog détient également les données nécessaires à l’intervention de l’équipe projet. Il est important de préciser que la réalisation du backlog scrum se déroule en plusieurs étapes, à savoir :
- la définition des objectifs du produit,
- leur matérialisation,
- l’identification des acteurs du projet,
- la délimitation des utilisateurs visés.
Suite à cela, il reste à établir une liste des exigences tant fonctionnelles que non fonctionnelles. Ces dernières sont appréciées au cas par cas, ainsi que leur coût de réalisation.
Différences entre un backlog et un cahier des charges
Il y a souvent confusion entre un backlog et un cahier des charges, pourtant, il s’agit bien de deux notions différentes.
Du point de vue du calendrier de travail, un cahier des charges est mis au point en début de projet, tandis qu’un backlog l’est au fur et à mesure. Le périmètre varie également entre les deux notions, un cahier des charges ayant un périmètre figé alors qu’un backlog a un périmètre évolutif.
S’agissant du budget, le budget indiqué dans un cahier des charges touche à un ensemble de fonctionnalités, tandis que le budget fixé par un backlog est relatif à un ensemble de ressources mobilisées.
Comment définir un backlog ?
Afin de correctement définir un backlog, il est important d’en déterminer les caractéristiques attendues, et cela de manière détaillée.
Avant tout, un backlog se définit d’abord à partir de la liste évolutive recensant l’intégralité des fonctionnalités. Tout l’intérêt de cette liste réside dans le fait qu’elle n’est pas fixée, qu’elle évolue au fur et à mesure de l’avancée du projet et des nouvelles estimations des besoins. L’ajout, la suppression ou encore la modification de tel ou tel élément est ainsi pleinement possible.
Ces fonctionnalités peuvent également être divisées en sous-catégories.
A travers le backlog, il est également possible de mettre en place un planning des livraisons. Ainsi, parmi les sous-éléments du backlog, figure la liste des fonctionnalités estimées comme finies à la date de livraison. Lorsqu’une analyse du backlog est réalisée à l’issue de chaque sprint, il devient possible et facile de suivre l’avancée de la réalisation de l’ensemble des fonctionnalités du produit.
Le timing joue un rôle tout aussi primordial dans la définition d’un backlog. Le backlog produit, pour être optimal, doit être constitué avant le lancement du premier sprint. En effet, lorsque le projet est encore en phase de préparation, on note que les multiples fonctionnalités utiles sont réparties en sous-catégories, suivant un ordre déterminé d’avance. Dans cette logique, le backlog produit est un outil démontrant une importance capitale dans le processus de planification et de réalisation du projet concerné.
Il est utile de préciser que tous les éléments composant le produit final seront référencés dans le backlog scrum, ce dernier étant rendu accessible à l’intégralité des acteurs liés au projet. Chaque participant a la capacité de jouer un rôle déterminant dans la collecte des éléments nécessaires. Cependant, la responsabilité d’accepter ou non ces éléments, ainsi que la responsabilité de définir les priorités, reviennent directement au Product Owner. En d’autres termes, le Product Owner est la personne chargée de la réalisation générale du backlog.
La méthodologie du Product Owner consiste à se renseigner auprès de chaque partie prenante au projet, et de s’en servir pour délimiter les contours du projet de backlog. D’un point de vue terminologique et technique, on distingue ainsi les « Features », les « Epics » et les « User stories » :
- Les « Features » désignent les toutes premières fonctionnalités,
- Ensuite, les « Epics », ou « User Stories », renvoient au découpage de ces fonctionnalités en sous-catégories prédéfinies, avec un ordre fixé suivant leur valeur.
Concernant la valeur de ces stories, leur détermination est simple à appréhender. Une story de forte valeur correspond à un produit dont le fonctionnement est peu coûteux, rapide, facile à implanter et à adapter. A contrario, une story de plus faible valeur correspondra à une fonctionnalité secondaire, c’est-à-dire une fonctionnalité demandant un développement complexe, lent, à un coût élevé.
S’agissant de la définition générale du backlog, cet ordre de valeur sera aisément visualisable. Ainsi, dans sa liste finale de fonctionnalités, on identifiera dans la partie supérieure les fonctionnalités aux valeurs les plus importantes, et en bas de la liste celles disposant des plus faibles valeurs.
L’ensemble de ce travail est primordial avant le lancement du premier sprint, car il constitue la toute première version du backlog. Cette étape préalable fait de ce fait office d’outil de planification. Ensuite, au fil des sprints et des remarques accumulées par les diverses parties, le backlog sera modifié et optimisé avec de nouvelles fonctionnalités. Cela sera également le cas dans le cadre de l’apparition de nouveaux besoins concrets.
Comment gérer son backlog ?
Gérer son backlog demande une première chose indispensable : le nettoyage régulier du backlog.
Accomplir un nettoyage régulier du backlog procure divers avantages, tels que conserver des fonctionnalités qualitatives, optimiser les chances d’atteindre l’objectif fixé, avoir des garanties que le processus suit la ligne directrice initialement instaurée, et enfin s’assurer que le backlog est fonctionnel.
La clé est de garder à l’esprit qu’il faut faire vivre son backlog, l’entretenir. L’objectif est de lui donner une importante valeur ajoutée. Cette gestion du backlog est déterminante. L’une des premières astuces de gestion de backlog, est de limiter le nombre d’éléments. L’idée est d’intégrer uniquement les idées les plus pertinentes au fur et à mesure de leurs éclosions, en inscrivant celles ayant la plus faible valeur sur une liste à part. L’atout principal de cette technique est de ne pas surcharger le backlog produit, les User Stories étant ainsi classées selon leur priorité.
Autre astuce : tenir un calendrier précis de rangement du backlog. En ce sens, l’intérêt est de concentrer les efforts sur les fonctionnalités urgentes et ayant la plus grande valeur, tout en préparant le sprint à venir. Par exemple, la cérémonie de backlog grooming permet de faire le point avec son équipe une fois par sprint.
Dernière astuce : s’appuyer sur un logiciel spécialisé en gestion de projet Agile. Un logiciel pensé sur-mesure pour la gestion de projet agile vous permettra de gagner un temps considérable ainsi que d’améliorer le suivi de votre backlog en général. Les principales fonctions de tels logiciels sont une optimisation de la communication entre toutes les parties, une augmentation de la visibilité sur l’ensemble des tâches en cours, ainsi qu’un accès à diverses notifications et divers indicateurs concernant l’évolution du projet agile.
Maintenant que la définition et la gestion d’un backlog ont été abordées, persiste la question de savoir pourquoi il est important de prioriser un backlog. Davantage de détails à suivre.
Pourquoi prioriser un backlog ?
Prioriser un backlog est une étape primordiale se justifiant de plusieurs manières. Tout d’abord, cela permet de mieux investir ses ressources. Pour y parvenir, il sera indispensable de minutieusement développer les fonctionnalités les plus importantes en terme de valeur, le tout en gardant une maîtrise sur le budget et sur les divers délais.
Outre cela, l’enjeu est de réaliser des livraisons aussi régulières et fiables que possible. Il s’agit plus précisément de livraisons des incréments du produit en cours de production.
Enfin, la gestion des risques constitue une autre motivation pour correctement prioriser un backlog. En effet, un backlog priorisé permettra d’avoir une visualisation efficace des différentes priorités ainsi que des urgences à ne pas laisser de côté. Sur ce point, une excellente communication entre les parties est un facteur primordial.
De multiples méthodes existent pour ce but, il appartient donc à chaque projet et à chaque équipe d’identifier et d’appliquer la méthode jugée la plus compatible.
MOSCOW, une méthode agile qui a fait ses preuves
MoSCoW est sans nul doute la méthode agile la plus plébiscitée sur le marché, afin de booster la priorisation backlog.
Développée par le consultant Dai Clegg, la méthode MoSCoW est un outil particulièrement utilisé dans le cadre des projets Agile. Son principe est le suivant : dépasser la simple notion “d’importance” des fonctionnalités, et aligner les visions de chacune des parties prenantes sur les tâches prioritaires devant être réalisées par l’équipe produit. Cette technique s’avère très efficace pour prioriser les User Stories suivant 4 niveaux :
- Mo, Must Have – dans cette catégorie, seuls prérequis ou encore les fonctionnalités indispensables au projet sont prises en comptes, en d’autres termes il s’agit des éléments sans lesquels le produit ne serait pas exploitable en production. Sans ces éléments, le produit s’avérerait être un véritable échec.
- S, Should Have – ici, il s’agit de regrouper les éléments ayant une importance élevée et qui apportent une forte valeur ajoutée au produit, toutefois sans lesquels le produit pourrait tout de même être déployé.
- Co, Could Have – on parle dans cette catégorie de User Stories dites « de confort », c’est-à-dire que ces stories ne seront réalisées que dans le cas où elles n’auraient pas d’impact sur les autres tâches, et si les délais du projet le permettent. Ces User Stories de confort représentent en quelque sorte des bonus destinés aux utilisateurs.
- W, Won’t have this time but would like in the future – ce type de tâches ne sont pas envisagées dans l’immédiat, elles sont uniquement souhaitables dans le futur dans l’hypothèse où le produit final devrait être amélioré.
WSJF, une priorisation encore plus poussée
WSJF fait référence à “Weighted Shortest Job First”, autrement dit “Le travail le plus lourd et le plus court en premier”.
Le WSJF constitue une technique de priorisation issue du framework SAFe, reposant sur une méthode de tri impartiale entre la valeur et l’effort de travail. Cette méthode est originale car elle se base sur le concept de “Cost of delay” (CoD) signifiant « le coût du retard ». Suivant ce concept, toute fonctionnalité non livrée à temps aura un certain coût.
Dans la logique générale, l’objectif est surtout de réduire tout éventuel coût de retard afin, en contrepartie, d’augmenter autant que possible l’efficacité du produit, et donc livrer le maximum de valeur lorsque le sprint prendra fin.
Dans le cadre du WSJF, plusieurs critères doivent être pris en compte :
- User Business Value : la valeur de la fonctionnalité,
- Job Size : l’effort de travail requis pour accomplir la fonctionnalité donnée,
- Time Criticality : il s’agit là de la criticité, c’est-à-dire la vitesse idéale à laquelle la fonctionnalité devrait être mise sur le marché,
- Risk Reduction / Opportunity Enablement : l’opportunité de développer de nouvelles fonctionnalités à partir de l’implémentation de la fonctionnalité initiale, ou encore la possibilité de réduire les risques liés au produit lui-même.
C’est à partir de ces trois facteurs que ce que l’on appelle le « coût du retard » peut être calculé. Plus précisément, il faut les additionner pour obtenir ce résultat.
À partir du résultat du coût du retard, le WSJF peut enfin aboutir. Pour chacune des User Stories à prioriser, il faudra réaliser l’estimation de l’effort de travail requis, et c’est alors que vous obtiendrez le WSJF. Information importante à retenir : plus la valeur du WSJF sera élevée, et plus l’élément évalué sera prioritaire.
Vous venez de voir notre présentation de ce qu’est le Backlog. N’hésitez pas à partager cet article autour de vous.
