Backlog produit dans Notion : l’écrire, le prioriser, le garder propre

Un backlog produit dans Notion est une base de données de stories, triée par priorité, où chaque ligne décrit une fonctionnalité vue par l’utilisateur. Il tient avec quatre propriétés indispensables (statut, epic, priorité, estimation), une méthode de priorisation simple comme MoSCoW ou RICE, et un affinage régulier pour que le haut de la liste soit toujours prêt.

Le backlog est la liste la plus importante d’une équipe produit, et souvent la plus mal tenue : des centaines de lignes, des doublons, des idées vagues mêlées à des stories prêtes.

Voici comment le construire dans Notion pour qu’il reste lisible, avec les choix que j’ai faits en concevant les bases de ProductOS. Le cadre complet des sprints est dans Scrum dans Notion.

Qu’est-ce qu’un backlog produit ?

Le backlog produit est la liste ordonnée de tout ce qui pourrait améliorer le produit. Le Scrum Guide en fait la seule source de travail de l’équipe, et confie au Product Owner la responsabilité de l’ordonner. Ce qui est en haut est prêt à entrer dans un sprint ; ce qui est en bas reste une idée.

Trois règles en découlent :

• Une seule liste pour le produit, même si plusieurs personnes y ajoutent des idées.
• Un ordre explicite : deux éléments ne peuvent pas être « tous les deux prioritaires ».
• Un niveau de détail qui varie : précis en haut, grossier en bas. Détailler une story qui ne sera pas faite avant six mois est du temps perdu.

Les propriétés d’une story bien écrite

Une story décrit un besoin du point de vue de l’utilisateur, souvent sous la forme : « En tant que [type d’utilisateur], je veux [action] afin de [bénéfice] ». Dans Notion, chaque story est une page de la base, avec quelques propriétés.

Les quatre indispensables :

1. Statut : Backlog, À affiner, Prête, puis les statuts du sprint. Le passage à « Prête » est une promesse : la story peut entrer en sprint sans question.
2. Epic : une relation vers le grand chantier auquel elle appartient. C’est ce qui permet de lire le backlog par thème.
3. Priorité : une sélection simple (P1 à P4) ou un score calculé, selon la méthode choisie plus bas.
4. Estimation : des points ou une taille (S, M, L). Elle sert à comparer la charge d’un sprint à la capacité de l’équipe.

Dans le corps de la page : les critères d’acceptation, une liste de conditions vérifiables. Une story sans critères n’est pas prête, quelle que soit la qualité de son titre.

Le repère classique pour juger une story est l’acronyme INVEST, proposé par Bill Wake : indépendante, négociable, apportant de la valeur, estimable, petite (small), testable.

Prioriser le backlog : trois méthodes qui marchent dans Notion

Il n’existe pas de méthode parfaite, seulement une méthode tenue dans la durée. Les trois suivantes se mettent en place en quelques minutes dans Notion.

MoSCoW

Chaque story reçoit une catégorie : Must (indispensable), Should (important), Could (souhaitable), Won’t (pas cette fois). Une sélection suffit. La méthode est rapide et parle aux parties prenantes, mais devient floue quand tout finit en « Must ».

RICE

Le score RICE, popularisé par l’équipe produit d’Intercom, combine quatre critères : la portée (Reach), l’impact, la confiance dans les estimations (Confidence) et l’effort. Le score vaut portée × impact × confiance ÷ effort. Dans Notion, quatre propriétés nombre et une formule donnent le score, et la vue se trie dessus. C’est la méthode que j’ai retenue pour classer les chantiers de VibecodingOS.

Valeur et effort

Deux notes de 1 à 5, une formule qui divise la valeur par l’effort. Les stories à forte valeur et faible effort remontent d’elles-mêmes. C’est la plus simple pour une petite équipe.

Mon conseil : commencez par valeur et effort, passez à RICE quand les débats sur les priorités deviennent fréquents. Le score ne décide pas à votre place, il rend le débat plus court.

Garder le backlog propre : l’affinage

Un backlog se dégrade tout seul. Les idées s’accumulent, les stories vieillissent, les doublons apparaissent. L’affinage est le moment où l’équipe le remet en état : compléter les stories du haut, découper celles qui sont trop grosses, supprimer ce qui ne sera jamais fait.

Dans Notion, trois vues font le travail :

• « À affiner » : les stories des deux ou trois prochains sprints qui n’ont pas encore de critères ou d’estimation.
• « Prêtes pour un sprint » : celles qui peuvent être tirées au planning, triées par priorité.
• « Par epic » : le backlog groupé par grand chantier, pour vérifier qu’aucun epic n’est oublié.

Une règle aide beaucoup : ce qui dort dans le backlog depuis plus de six mois sans avoir bougé se supprime ou s’archive. S’il revient, il reviendra mieux formulé.

Du backlog à la roadmap

La roadmap n’est pas une seconde liste : c’est le backlog vu de loin. Dans Notion, elle se construit sur la base Epics, en vue timeline, avec une date de début et de fin par epic. Les stories restent dans le backlog ; la roadmap montre seulement quels chantiers avancent, et quand.

Deux précautions :

• Pas de dates fines au-delà de quelques semaines. Une roadmap par trimestre, ou en trois colonnes « Maintenant, Ensuite, Plus tard », promet moins et se tient mieux.
• L’avancement calculé, pas déclaré : un rollup sur les stories terminées de chaque epic dit où il en est vraiment. Le principe est dans la vue timeline de Notion.

Qui peut écrire dans le backlog ?

Tout le monde peut proposer, une seule personne ordonne. Dans Notion, le plus simple est un formulaire ou une vue « Proposer une idée » qui crée une story au statut « Backlog ». Le Product Owner la trie à l’affinage suivant : il la garde, la fusionne avec une autre ou la refuse.

Ainsi le support client, les commerciaux ou les utilisateurs alimentent le backlog sans le désorganiser.

Partir d’un template

ProductOS contient le backlog décrit ici : les stories reliées aux epics et aux sprints, les vues « À affiner », « Prêtes pour un sprint » et « Par epic », la roadmap en timeline et la page du Product Owner, avec ce qui est à valider et à affiner.

Découvrir ProductOS

Questions fréquentes