Scrum dans Notion : organiser les sprints de toute l’équipe produit
Faire du Scrum dans Notion : les bases reliées, le tableau du sprint, chaque rituel du planning à la rétrospective, et une page par métier de l’équipe.
Pour faire du Scrum dans Notion, il faut quatre bases reliées : les epics, les stories, les tâches et les sprints. Chaque story appartient à un sprint, chaque sprint a un objectif et une capacité, et un tableau filtré sur le sprint en cours devient le support du daily. Les rituels du Scrum se tiennent ensuite dans Notion, comptes rendus compris.
Beaucoup d’équipes commencent par un simple tableau Kanban dans Notion, puis se heurtent au même mur : impossible de savoir ce qui était prévu dans le sprint, ce qui a glissé, et pourquoi.
Ce guide montre la structure qui tient, celle que j’ai construite pour ProductOS, mon template Scrum pour les équipes produit, et la façon d’y faire vivre chaque rituel. Si le Kanban seul vous suffit, le guide du tableau Kanban dans Notion est plus adapté.
Scrum ou Kanban dans Notion : quelle différence ?
Le Kanban organise un flux continu : des colonnes, des cartes qui avancent, une limite au travail en cours. Scrum découpe le temps en sprints de durée fixe, chacun avec un objectif, et se termine par une démonstration de ce qui est fait. Dans Notion, la différence se voit à une base : Scrum ajoute une base « Sprints ».
- Kanban suffit si votre équipe traite des demandes au fil de l’eau, sans échéance de livraison commune.
- Scrum s’impose si vous livrez un produit par incréments, avec un Product Owner qui priorise et des parties prenantes à qui montrer l’avancement.
Les deux se combinent : le tableau du sprint, dans Scrum, est lui-même un Kanban.
Ce que dit le Scrum Guide, en bref
Le Scrum Guide, écrit par Ken Schwaber et Jeff Sutherland, est la référence. Sa version de 2020 est courte, et trois idées suffisent pour construire l’espace Notion :
- Trois responsabilités : le Product Owner, qui maximise la valeur du produit et ordonne le backlog ; le Scrum Master, garant du cadre ; les Developers, qui réalisent l’incrément.
- Trois artefacts : le Product Backlog, le Sprint Backlog et l’Incrément, chacun avec son engagement (l’objectif produit, l’objectif du sprint, la définition de « terminé »).
- Un sprint d’un mois au plus, qui contient tous les événements : planning, daily, review et rétrospective.
Le guide ne parle ni de points, ni de stories, ni de vélocité : ce sont des pratiques courantes, pas des règles. Notion permet de les ajouter, sans les imposer.
Les bases Notion d’un Scrum qui tient
Quatre bases portent l’essentiel. Les autres (bugs, cas de test, releases, documentation) s’ajoutent quand l’équipe en a besoin.
Epics
Les grands chantiers du produit, sur plusieurs sprints : « Paiement en ligne », « Espace client ». Un rollup calcule leur avancement à partir des stories terminées.
Stories
L’unité de travail du backlog : une fonctionnalité vue par l’utilisateur, avec ses critères d’acceptation, son estimation et son statut. Chaque story est reliée à un epic et, quand elle est prête, à un sprint. Comment les écrire et les prioriser est détaillé dans le backlog produit dans Notion.
Tâches
Le découpage technique d’une story, fait par les Developers pendant le planning. Une story se termine quand ses tâches sont faites et ses critères vérifiés.
Sprints
Une page par sprint, avec ses dates, son objectif et sa capacité. Un rollup additionne les points des stories rattachées : vous voyez au planning si l’équipe s’engage sur plus qu’elle ne peut livrer.
Le tableau du sprint
Le tableau du sprint est une vue Kanban de la base Stories, filtrée sur le sprint en cours et groupée par statut. C’est la page ouverte au daily, et la seule dont l’équipe a besoin au quotidien.
Trois réglages le rendent utile :
- Un filtre sur le sprint en cours, et non sur une date : le tableau change tout seul au sprint suivant si vous cochez le sprint actif.
- Des statuts qui disent qui a la main : À faire, En cours, En revue, En recette, Terminé. Une carte en revue attend un relecteur, pas le développeur.
- Une vue « Ce qui bloque », filtrée sur une case « Bloquée » : c’est la première chose regardée au daily.
Les rituels d’un sprint dans Notion
Le Scrum Guide fixe une durée maximale pour chaque événement d’un sprint d’un mois. Pour un sprint de deux semaines, les durées se réduisent en proportion, sauf le daily qui reste à quinze minutes.
Sprint planning
Le premier jour du sprint, toute l’équipe. Le Product Owner propose un objectif et les stories prêtes les plus prioritaires ; l’équipe choisit ce qu’elle peut livrer, puis découpe en tâches. Dans Notion : renseignez l’objectif et la capacité du sprint, rattachez les stories depuis une vue « Prêtes pour un sprint », et surveillez la charge calculée.
Daily
Chaque jour, quinze minutes, devant le tableau du sprint. Chacun dit ce qui avance vers l’objectif et ce qui le bloque. Pas de compte rendu : le tableau à jour en tient lieu.
Affinage du backlog
Pas un événement au sens du Scrum Guide, mais une activité continue. En pratique, un créneau en milieu de sprint pour compléter les stories du sprint suivant : critères, estimation, maquette. Dans Notion, on travaille dans une vue « À affiner » et on passe chaque story complète au statut « Prête ».
Sprint review et rétrospective
Le dernier jour, la review montre ce qui est terminé aux parties prenantes, puis la rétrospective, entre membres de l’équipe, choisit une ou deux améliorations pour le sprint suivant. Une base « Comptes rendus », reliée aux sprints, garde la trace de ce qui a été décidé, et quand.
Une page par métier dans l’équipe
Ce que la construction de ProductOS m’a appris : chaque métier cherche autre chose dans le même backlog. Le Product Owner veut ce qui est à valider et à affiner ; le développeur, ses tâches et ses revues ; le designer, les maquettes à livrer ; le testeur, ce qui est à recetter.
Plutôt que d’imposer la même vue à tous, donnez à chacun une page avec ses vues filtrées sur son nom. Tout le monde travaille sur les mêmes stories, mais personne ne trie ce qui ne le concerne pas. Pour les droits d’accès de chacun, voyez les permissions Notion en équipe.
Les erreurs fréquentes d’un Scrum dans Notion
- Une seule base pour tout : epics, stories et tâches mélangés dans une table, impossibles à filtrer proprement.
- Des sprints sans objectif : une liste de stories n’est pas un sprint. L’objectif dit ce qui compte si tout ne rentre pas.
- Le tableau qui n’est jamais à jour : si le daily se fait à l’oral et le tableau le vendredi, il ne sert plus à rien. Mettez-le à jour pendant le daily.
- Trop de propriétés : chaque champ obligatoire ralentit l’écriture d’une story. Commencez avec le statut, l’epic, le sprint, l’estimation et les critères.
Template ou construction maison ?
Construire l’espace soi-même est tout à fait possible : chaque base, chaque relation et chaque vue filtrée se règle à la main. Un template fait gagner ce temps et arrive avec les rituels déjà décrits.
ProductOS installe le Scrum complet de l’équipe produit dans Notion : les epics, les stories, les tâches, les sprints, les bugs, les cas de test, les releases et la documentation, reliés, avec une page pour le PO, le développeur, le designer et le testeur. Un seul paiement couvre toute l’équipe.
Questions fréquentes
Peut-on faire du Scrum dans Notion ?
Oui. Il faut des bases reliées pour les epics, les stories, les tâches et les sprints, puis un tableau filtré sur le sprint en cours pour le daily. Les rituels, du planning à la rétrospective, se tiennent dans Notion avec une base de comptes rendus reliée aux sprints.
Quelle durée pour un sprint Scrum ?
Le Scrum Guide fixe un mois au plus. Beaucoup d’équipes choisissent deux semaines, assez long pour livrer quelque chose de montrable, assez court pour corriger le tir vite. L’essentiel est de garder la même durée d’un sprint à l’autre, pour comparer.
Faut-il des points d’estimation dans Notion ?
Ce n’est pas obligatoire : le Scrum Guide n’en parle pas. Les points aident à comparer la charge d’un sprint à la capacité de l’équipe. Dans Notion, une propriété nombre sur la story et un rollup sur le sprint suffisent pour voir si l’équipe s’engage sur trop.
Notion convient-il à une équipe agile de plusieurs métiers ?
Oui, à condition de donner à chaque métier sa page, avec des vues filtrées sur son nom : le Product Owner, le développeur, le designer et le testeur travaillent sur les mêmes stories sans trier ce qui ne les concerne pas. Les permissions se règlent par espace.
Existe-t-il un template Notion Scrum ?
ProductOS est un template Notion Scrum pour toute l’équipe produit : epics, stories, tâches, sprints, bugs, cas de test, releases et documentation reliés, avec une page par métier et les rituels décrits. Un seul paiement couvre toute l’équipe.