Backlog produit : le modèle Excel, la priorisation et un exemple rempli

Ce que contient le classeur de backlog produit

Le classeur Excel proposé ici contient cinq onglets. Le deuxième est le document de travail : une ligne par besoin, avec un identifiant, l’épopée à laquelle il appartient, les trois colonnes qui forment la phrase, la priorité, l’estimation en points, le gabarit concerné, les critères d’acceptation et le statut. Les listes déroulantes et la coloration automatique de la priorité rendent le tableau triable et lisible d’un coup d’œil.

Le troisième onglet contient vingt lignes entièrement rédigées sur un projet fictif de plateforme web, critères d’acceptation compris. C’est la partie la plus utile du fichier : partir d’exemples concrets fait gagner plus de temps que lire une méthode. Le quatrième compte les lignes et les points par priorité, ce qui permet de voir en une seconde si le périmètre de la première version est arbitré.

Comment construire un backlog produit, étape par étape

Partez de l’expression de besoin, pas d’une page blanche. Chaque besoin classé devient une ou plusieurs lignes de backlog ; la traçabilité entre les deux documents évite la dérive la plus courante, celle du backlog qui grossit de lignes dont plus personne ne sait d’où elles viennent ni qui les a demandées.

Écrivez chaque ligne en trois temps : en tant que tel profil, je veux obtenir telle chose, afin de telle raison. La troisième partie est celle qu’on saute le plus souvent et celle qui sert le plus : elle dit pourquoi la ligne existe, donc ce qui est négociable si le budget se resserre. Une ligne dont personne ne sait écrire le « afin de » est presque toujours une ligne dont personne n’a besoin.

Nommez le profil avec précision. « En tant qu’utilisateur » ne renseigne personne, parce que tous les utilisateurs n’ont ni les mêmes droits ni les mêmes conditions. « En tant que client connecté disposant d’un tarif négocié » et « en tant qu’administrateur des ventes » décrivent deux parcours, deux gabarits et deux chiffrages différents.

Écrivez les critères d’acceptation avant le développement, jamais après. Ils se formulent en trois temps : étant donné une situation de départ, quand telle action a lieu, alors tel résultat observable se produit. Cette forme rend la validation mécanique : ou bien le résultat est là, ou bien il ne l’est pas. Sans critères écrits, la validation devient une conversation d’impressions, et cette conversation se rejoue à chaque livraison.

Donnez une priorité MoSCoW à chaque ligne. Must désigne ce sans quoi la première version n’a pas de sens. Should désigne ce qui est important mais dont l’absence n’empêche pas le site de fonctionner. Could désigne ce qui se fera si le budget le permet. Won’t désigne ce qui est écarté de cette version, et c’est la catégorie la plus utile : elle transforme un désaccord latent en décision datée, qui ne revient plus à chaque comité.

Estimez en points, pas en jours, sur l’échelle 1, 2, 3, 5, 8, 13. L’estimation relative se révèle plus fiable qu’une estimation en jours faite avant la conception, parce qu’elle compare les lignes entre elles au lieu de prédire un avenir inconnu. Laissez-la à l’équipe qui développera : une estimation imposée par l’acheteur n’est pas une estimation, c’est une contrainte déguisée.

Ordonnez, enfin, et c’est ce qui distingue un backlog d’une liste. Les priorités MoSCoW donnent quatre paquets ; à l’intérieur d’un paquet, l’ordre reste à décider. La première ligne du backlog est ce qui sera fait ensuite, et cette place se mérite : la plus forte valeur, la plus faible incertitude, ou la dépendance qui bloque le reste.

Un exemple rempli, sur un cas fictif

Les quatre lignes ci-dessous viennent de l’onglet « Exemple rempli » du classeur, qui en contient vingt. Elles portent sur une société entièrement fictive, « Sorel Équipement », distributeur d’outillage professionnel.

Comment découper une ligne trop grosse

Le découpage est l’exercice qui décide de la qualité d’un backlog, et il se rate presque toujours de la même manière : par couche technique. « Créer le modèle de données », « développer l’interface », « brancher l’outil de gestion » ne sont pas trois lignes, ce sont trois moitiés de la même chose, dont aucune ne peut être montrée ni validée séparément.

Le premier axe de découpage utile est le profil. « Consulter le catalogue » donne au moins deux lignes distinctes dès qu’il existe des tarifs négociés : le visiteur voit le tarif public, le client connecté voit le sien. Les deux se développent, se testent et se livrent séparément, et la première a souvent une valeur immédiate sans la seconde.

Le deuxième axe est l’étape du parcours. Une commande en ligne se découpe en ajouter au panier, valider, recevoir un récapitulatif, retrouver la commande dans son historique. Chaque étape se montre, chaque étape se teste, et l’ordre de livraison devient une décision d’arbitrage plutôt qu’une contrainte technique.

Le troisième axe est la règle de gestion. Le cas nominal donne une ligne, chaque cas particulier en donne une autre : encours dépassé, référence épuisée, quantité minimale non atteinte. Ce découpage a un avantage inattendu lors de la consultation : il rend visible, dans le devis, ce que coûtent réellement les cas particuliers, que les propositions au forfait noient habituellement dans un total.

Le dernier axe est la variante de support. Un parcours utilisable au clavier et un parcours pensé pour un écran de téléphone ne sont pas des détails d’intégration : ce sont des exigences qui se testent, donc qui méritent leur ligne et leurs critères d’acceptation. Les écrire séparément est la seule façon simple d’éviter qu’elles disparaissent du périmètre au premier resserrement de budget.

Les erreurs qui coûtent le plus cher

Un backlog mal tenu ne se voit pas tout de suite. Il se voit à la troisième itération, quand plus rien ne se valide et que les mêmes discussions reviennent.

• Écrire un écran au lieu d’un besoin. « Créer la page Mon compte » n’est pas une ligne de backlog : c’est une tâche, elle ne se valide pas et elle n’a pas de « afin de ». Le besoin est « retrouver mes factures sans appeler », et la page n’est qu’une des réponses possibles.
• Laisser les critères d’acceptation pour plus tard. Écrits après le développement, ils décrivent ce qui a été fait, pas ce qui était attendu. C’est le mécanisme exact par lequel une livraison conforme au document devient inutilisable sur le terrain.
• Empiler sans jamais ordonner. Un backlog qui s’allonge sans que sa première ligne change n’est pas un backlog, c’est une boîte à idées. L’ordre est l’information la plus utile du document.
• Garder des lignes à vingt points. Elles bloquent une itération entière, masquent l’avancement réel et rendent toute prévision impossible. Découpez par parcours ou par profil, jamais par couche technique.
• Ne jamais employer Won’t. Un backlog sans catégorie Won’t est un backlog où rien n’est jamais écarté. Les mêmes demandes reviennent à chaque comité, et chaque comité les réexamine. Écarter par écrit coûte une ligne et fait gagner des heures.

Backlog et devis : ce que le prestataire en fait

Un backlog priorisé transforme la lecture d’un devis. Une agence qui reçoit cinquante lignes ordonnées chiffre un périmètre, pas une impression, et elle peut proposer un découpage en versions successives plutôt qu’un forfait unique. C’est souvent la différence entre un projet qui démarre sur l’ensemble et un projet qui démarre sur le Must, le reste étant engagé après une première mise en ligne et une première mesure.

Le backlog sert ensuite à piloter. À chaque itération, ce qui est terminé est terminé au sens des critères d’acceptation, et l’avancement se mesure en points validés plutôt qu’en pourcentage déclaré. C’est aussi le document qui permet d’accepter un ajout sans dériver : une ligne qui entre en cours de route en fait sortir une autre de même taille, décision prise par vous, tracée dans la colonne de priorité.

Le circuit complet part de l’expression de besoin, qui devient le backlog, puis du cahier des charges pour la consultation, et se lit enfin sur la grille des devis. Les fourchettes de référence sont publiées sur la page prix d’un site internet.

Les autres modèles du guide

• Expression de besoin : le document à rédiger avant le cahier des charges
• Wireframe : douze exemples de gabarits de pages et le modèle à réutiliser
• Arborescence de site web : le modèle à remplir et trois exemples commentés

Tous les modèles sont réunis sur le hub des ressources. Le document qui les rassemble reste le cahier des charges de site internet : c’est lui qui part aux prestataires. Les fourchettes de prix publiées et la grille de lecture des devis servent ensuite à comparer les réponses ligne à ligne.