Qu’est-ce que le Scrumban ?

Ce qu’est vraiment le Scrumban

Le Scrumban garde les parties de Kanban et de Scrum qui gagnent leur place, et laisse le reste. De Kanban, il prend le tableau visuel, le flux par colonnes et une limite explicite sur la quantité de travail en cours — ce qui rend le flux lisible. De Scrum, il prend le sprint limité dans le temps — ce qui transforme un backlog en plan.

Ce qu’il laisse de côté : les standups quotidiens, les réunions de grooming, les cérémonies de story points, la rétrospective comme rituel. Cela marche pour dix ingénieurs dans une organisation rodée ; cela ne marche pas pour un fondateur qui essaie de livrer un samedi.

Le nom vient de Corey Ladas, dont l’essai puis le livre Scrumban décrivaient comment des équipes Scrum pouvaient passer d’itérations fixes à un flux tiré.

Scrumban, Kanban ou Scrum : quelles différences ?

Les trois diffèrent surtout sur deux points : le travail est-il planifié par périodes fixes, et combien de process entoure le tableau.

Sources : le Scrum Guide pour les sprints, les rôles et les événements ; le Kanban Guide pour le flux et les limites du travail en cours.

À quoi ressemble un tableau Scrumban ?

Un tableau Scrumban est un tableau Kanban sur lequel on pose un sprint. Les colonnes montrent où en est le travail ; le sprint dit sur quelle partie du backlog porte la semaine. Un tableau minimal a quatre colonnes :

• Backlog — tout ce que vous pourriez faire. En vrac en bas, trié en haut.
• Todo — ce que vous avez décidé de faire ensuite. Volontairement court : quand il se vide, c’est le signal pour planifier.
• Doing — ce sur quoi quelqu’un (une personne ou un agent IA) travaille en ce moment.
• Done — le travail terminé. Vidé ou archivé à la fin d’un sprint.

Comment mettre en place un tableau Scrumban ?

1. Créez les quatre colonnes : Backlog, Todo, Doing, Done.
2. Mettez dans Backlog tout ce que vous avez en tête. Ne triez pas tout — triez le haut.
3. Décidez combien de choses peuvent être dans Doing en même temps. Pour une personne, une ou deux ; pour une petite équipe, environ une par personne.
4. Choisissez une durée de sprint — une ou deux semaines — et donnez-lui un objectif en une phrase. Ne tirez dans Todo que ce qui sert cet objectif.
5. Travaillez en flux tiré : quand quelque chose dans Doing est terminé, prenez la carte suivante en haut de Todo. Personne n’impose du travail à personne.
6. Planifiez quand Todo se vide, pas selon un calendrier. À la fin du sprint, regardez ce qui a été fait et ce qui ne l’a pas été, puis lancez le suivant.

Pourquoi Weft choisit le Scrumban

Weft existe parce que la plupart des gestionnaires de tâches sont taillés pour l’un de deux extrêmes : soit une appli de to-do solitaire (liste infinie, aucune cadence), soit une suite Agile pour cinquante personnes (du process pour un fondateur seul). Le Scrumban se place pile au milieu — assez de structure pour forcer une livraison hebdomadaire ou bimensuelle, pas assez pour que vous passiez le jour de livraison à l’administrer.

Comment Weft l’implémente

• Quatre colonnes par défaut : Backlog, Todo, Doing, Done. Le travail en cours est limité par ce qui vous attend, pas par un chiffre par colonne. Le Kanban Guide fait d’une règle explicite de limitation du travail en cours une partie de la définition du workflow, pour que de nouveaux éléments ne soient tirés qu’à mesure que de la capacité se libère.
• Un seul sprint actif à la fois, avec un objectif facultatif. Les sprints sont facultatifs — sautez-les si le Kanban pur vous convient. Le Scrum Guide définit les Sprints comme des événements de durée fixe, d’un mois maximum, un nouveau Sprint commençant immédiatement après la fin du précédent.
• Les tâches ont une priorité, une estimation, une échéance et un rattachement facultatif à un sprint. Pas d’epics, pas de workflows, pas de champs personnalisés.
• Le temps de cycle démarre quand une tâche entre dans une colonne marquée semantic="doing" et s’arrête en "done". Les chiffres viennent d’un usage honnête, pas d’une arithmétique de story points.

Le Scrumban avec des agents IA

C’est le flux tiré qui fait aussi fonctionner le Scrumban pour les agents IA. Un agent connecté à Weft via MCP prend lui-même la carte suivante : start_task la réserve, pour qu’un second agent ne puisse pas prendre la même carte, et complete_task la termine avec ce qui a été fait et les preuves. Quand un agent a besoin d’une décision, il vous la demande au lieu de deviner — et tant que trop de travail terminé vous attend, les agents cessent de commencer de nouvelles tâches. C’est la limite Kanban du travail en cours, appliquée à la seule ressource qui ne passe pas à l’échelle : votre attention.

Quand le Scrumban n’est pas la bonne méthode

• Vous faites tourner plusieurs équipes Scrum en parallèle. Le Scrum Guide fixe la taille d’une Scrum Team à 10 personnes ou moins en général, et indique que les produits plus grands doivent être organisés en plusieurs Scrum Teams partageant un même Product Goal et un même Product Backlog. Reporting au niveau programme, vélocité partagée, dépendances inter-équipes — le Scrum complet dans Jira mérite alors son coût. Le Nexus Guide est écrit pour cette situation : plusieurs Scrum Teams travaillant sur un seul Product Backlog, avec des pratiques supplémentaires pour faire apparaître et résoudre les dépendances entre équipes.
• Vous faites du support pur ou de l’exploitation continue. Aucune cadence de sprint nécessaire — le Kanban pur ou un système de tickets convient mieux.
• Vous avez besoin de diagrammes de Gantt et de plannings. Le Scrumban est centré sur les sprints, pas sur les graphes de dépendances.

Questions sur le Scrumban