Comment Scrum et Kanban gèrent-ils la capacité d'une équipe ?
Scrum borne la charge par l'engagement de sprint : l'équipe s'engage sur ce que sa capacité de l'itération permet, en tenant compte des absences. Kanban la borne par des limites de travail en cours (WIP) : l'équipe ne démarre rien de nouveau tant qu'elle a atteint la limite. Dans les deux cas, une capacité réaliste reste nécessaire pour dimensionner l'engagement ou la limite.
Kanban, Scrum et capacité
Scrum borne la charge par itération, Kanban par limites de travail en cours.
Dernière mise à jour :
Scrum : capacité par itération
- La capacité du sprint se calcule à partir des jours disponibles et de la vélocité.
- L'équipe s'engage sur un périmètre compatible avec cette capacité.
- Les absences, congés et événements sont déduits avant l'engagement.
Kanban : capacité par flux
- Des limites de travail en cours empêchent d'ouvrir trop de chantiers à la fois.
- Le débit (éléments terminés par période) remplace la vélocité.
- La capacité sert à fixer des limites cohérentes avec la taille de l'équipe.
Ce qui les rapproche
- Les deux évitent la surcharge en refusant de démarrer plus que ce que l'équipe peut absorber.
- Aucune des deux ne dit comment partager une personne entre plusieurs équipes : c'est le rôle d'une vue de capacité consolidée.
FAQ
Faut-il un outil de capacité avec Kanban ?
Pour une équipe isolée, non. Dès que des personnes sont partagées entre équipes ou projets, une vue de capacité consolidée évite les doubles affectations.
Quelle différence entre vélocité et débit ?
La vélocité mesure les points terminés par itération ; le débit compte les éléments terminés par unité de temps.
Les limites de WIP remplacent-elles la capacité ?
Non, elles la protègent : la capacité aide à les dimensionner.
Pour aller plus loin
Explorer aussi
Passez de la théorie à votre plan de charge
Importez vos équipes et vos projets en CSV et visualisez capacité et surcharges en une demi-heure.
Essai gratuit 14 jours