Mener des sprints dans une petite équipe de cinq : trois réunions, deux chiffres, pas de story points

La réponse courte : trois réunions et deux chiffres

Un sprint est une période fixe pendant laquelle l'équipe s'engage sur un ensemble de travail choisi. À cinq, ce qui sert, c'est l'engagement et la date de fin fixe. Les deux obligent à parler de ce qui compte cette quinzaine et rendent les dérapages visibles tôt.

Ce dont une équipe de cinq n'a pas besoin, c'est d'un processus conçu pour coordonner plusieurs équipes, d'un Scrum Master à plein temps ou d'un système de prévision fondé sur des estimations. Le Guide Scrum lui-même décrit des équipes de dix personnes ou moins en général et autorise jusqu'à huit heures de planification pour un sprint d'un mois. À cinq personnes et deux semaines, ce budget dépasse largement le besoin.

La méthode garde donc :

• Une durée, fixe. Deux semaines sauf raison précise. Changer de durée à chaque sprint rend toute comparaison impossible.
• Un objectif par sprint. Une phrase, pas une liste. « Les clients peuvent payer sur facture » est un objectif ; « avancer sur la facturation » n'en est pas un.
• Trois réunions. Planification, point à mi-parcours, démo. Environ 90 minutes de réunion sur dix jours ouvrés.
• Deux chiffres. Le débit (tickets terminés) et le report (tickets qui passent au sprint suivant).

Pourquoi Scrum complet, c'est trop pour cinq personnes

Les événements Scrum ont de bonnes raisons d'exister, et les durées du Guide sont des maximums, pas des cibles. Le problème pour une petite équipe, c'est le coût fixe. Un daily de 15 minutes coûte à une équipe de cinq 75 minutes-personne par jour, soit environ six heures-personne par sprint de deux semaines avant même le moindre dépassement. Une rétrospective à chaque sprint, une séance d'affinage et une revue s'y ajoutent.

À cinq, presque tout ce que ces réunions font remonter est déjà visible. Tout le monde voit le tableau, tout le monde est dans le même chat, et la personne bloquée par une décision d'API le dit en général dans l'heure. Les réunions qui restent rentables sont celles qui forcent une décision que personne ne prendrait autrement : sur quoi on s'engage, si on est toujours dans les temps, et si ce qu'on a construit tient la route.

Dans notre propre travail, les réunions que nous avons supprimées étaient celles qui répétaient ce que le tableau montrait déjà : le tour de table quotidien et le débat sur les estimations. Celles que nous avons gardées sont celles où l'équipe doit choisir ensemble.

Le sprint minimal pour une équipe de cinq

Voici ce que nous gardons de chaque événement Scrum, et ce qui remplace le reste.

Le temps de réunion total se situe entre environ 90 minutes et deux heures et demie par sprint, contre huit heures ou plus pour la version au pied de la lettre.

Mener un sprint de deux semaines, étape par étape

Les étapes supposent deux semaines, dix jours ouvrés et un backlog déjà à peu près ordonné. Si votre backlog est en désordre, passez une heure à trier les 20 premiers éléments avant la première planification ; c'est l'heure la plus rentable que vous passerez.

Jour 1 : planification (45 minutes)

1. Regardez les chiffres du sprint précédent (5 minutes). Combien de tickets terminés, combien reportés. C'est votre repère de capacité.
2. Écrivez l'objectif (10 minutes). Une phrase qui dit ce qui sera vrai à la fin. La personne responsable du produit le propose ; l'équipe le discute.
3. Prenez le travail qui sert l'objectif (20 minutes). Depuis le haut du backlog, prenez des tickets jusqu'à atteindre à peu près le débit du sprint précédent. Tout ce qui ne sert pas l'objectif doit justifier sa présence.
4. Donnez un responsable à chaque ticket (5 minutes). Une seule personne. Un ticket partagé est un ticket sans responsable.
5. Nommez le risque (5 minutes). Ce qui a le plus de chances de faire échouer l'objectif. Écrivez-le sous l'objectif.

Le modèle de planification de sprint contient cet ordre du jour, un tableau de capacité et une place pour l'objectif, et fonctionne que vous parliez de sprint ou de cycle.

Chaque jour : un point asynchrone au lieu d'un daily

Chacun écrit deux ou trois lignes dans un fil du chat d'équipe en milieu de matinée : ce qu'il a terminé, ce sur quoi il travaille et ce qui le bloque. Deux minutes pour écrire, deux pour lire. Les blocages se règlent par une réponse dans le fil ou un appel rapide entre les deux personnes concernées, pas par une réunion à cinq.

Jour 6 : le point à mi-parcours (15 minutes)

C'est la réunion que Scrum n'a pas et dont les petites équipes ont le plus besoin. À mi-chemin, regardez le tableau et posez une seule question : allons-nous atteindre l'objectif ? Si la réponse est non, décidez maintenant ce que vous retirez, pas le jour dix. Sortir deux tickets le jour six, c'est un plan. Découvrir le jour dix que quatre tickets n'ont pas été faits, c'est une surprise.

Jour 10 : démo et clôture (30 minutes)

Montrez ce qui a été livré, dans le produit, pas en diapositives. Puis clôturez le sprint : ce qui est terminé est fait, et chaque ticket inachevé passe au sprint suivant ou retourne au backlog. Décidez-le volontairement. Consacrez les cinq dernières minutes à une question, « que devrions-nous faire autrement la prochaine fois ? », et notez au plus un changement.

Quoi mesurer : le débit et le report

Deux chiffres suffisent à une équipe de cinq.

Le débit, c'est le nombre de tickets terminés dans le sprint. Compter des tickets est plus grossier que les points, mais difficile à manipuler et sans réunion d'estimation. Sur trois ou quatre sprints, il se stabilise dans une fourchette, par exemple 18 à 24 tickets pour une équipe de cinq, et cette fourchette devient votre capacité pour la planification suivante. Cela marche mieux si les tickets ont des tailles comparables : découpez tout ce qui prendrait plus de trois ou quatre jours.

Le report, c'est le nombre de tickets du sprint qui n'ont pas été terminés. Un peu, c'est normal. Beaucoup, ou le même ticket reporté trois sprints de suite, c'est le signal qui compte : l'équipe planifie trop, le ticket est trop gros, ou il est bloqué par quelque chose que personne n'a nommé. À chaque planification, nous regardons le report avant le débit.

Si vous voulez un troisième chiffre, suivez la fréquence à laquelle l'objectif du sprint est atteint. Une équipe qui l'atteint quatre sprints sur cinq, même avec quelques reports, fonctionne bien.

Ce qu'on peut laisser tomber : story points, vélocité et la plupart des graphiques

Les story points servent à prévoir combien de travail tient dans une période. À cinq, leur prévision est rarement meilleure que le simple comptage des tickets, et les réunions d'estimation coûtent du temps réel. Ils se justifient quand vous devez annoncer des dates de livraison à un client à partir de l'historique, ou quand la taille des tickets varie énormément sans pouvoir les découper. Sinon, laissez-les de côté.

Les graphiques de vélocité découlent des points, ils partent donc aussi. Les diagrammes de flux cumulé et équivalents sont utiles à vingt ; à cinq, le tableau lui-même montre où le travail bloque.

Un burndown des tickets ouverts est le seul graphique à garder, parce qu'il répond d'un coup d'œil à la question de mi-parcours.

Linear, Jira et Atrix pour les sprints d'une petite équipe

Les trois gèrent bien les sprints d'une petite équipe. Ils diffèrent par ce qu'ils décident à votre place. Les données viennent de la documentation et des pages tarifaires de chaque éditeur, en octobre 2026.

Linear est le plus proche de la méthode décrite ici. Sa documentation sur les cycles décrit le report automatique, un cooldown facultatif entre les cycles et une capacité estimée sur les trois derniers cycles terminés. Pour une équipe de cinq, la page tarifaire de Linear affiche un plan gratuit qui couvre les petites équipes jusqu'à 250 tickets.

Jira offre le plus de contrôle. Quand vous terminez un sprint, la documentation de Jira propose trois destinations pour le travail inachevé : le backlog, un sprint futur déjà créé ou un nouveau sprint. C'est le bon choix si vous voulez qu'une personne décide du report à chaque fois, et le plan gratuit de Jira couvre jusqu'à 10 utilisateurs.

Atrix est l'outil que nous développons, alors commençons par ses limites. Il propose des cycles d'une à quatre semaines par produit, chacun avec un objectif et un burndown qui compte les tickets ouverts, et la clôture d'un cycle fait passer le travail inachevé au suivant ou le renvoie au backlog. Les étiquettes en couleur et les jalons sont à côté. Il n'a volontairement ni story points, ni rapports de vélocité, ni réglage de cooldown ; si votre processus en dépend, prenez Linear ou Jira. Atrix a du sens quand l'équipe veut aussi des documents, un chat, un CRM et le recrutement dans le même espace. La page gestion de projet détaille ce qu'il fait, et notre comparatif avec Linear dit franchement où Linear fait mieux.

Les échecs fréquents des sprints en petite équipe

• Pas d'objectif, juste une liste. Sans une phrase d'intention, tous les tickets semblent aussi importants et rien n'est retiré à mi-parcours.
• Planifier sur l'espoir plutôt que sur l'historique. Si vous avez terminé 20 tickets au dernier sprint, en prévoir 35 n'est pas de l'ambition : c'est du report programmé d'avance.
• Sauter le point à mi-parcours. La surprise de fin de sprint existait presque toujours dès le jour six.
• Des tickets trop gros pour être finis. Un ticket qui occupe tout le sprint ne vous apprend rien avant le dernier jour. Découpez-le.
• Changer de durée. Un sprint d'une semaine après un sprint de trois rend tous les chiffres inutilisables.

Pour la différence entre les mots sprint et cycle, et pourquoi certains outils reportent le travail sans demander, lisez cycles ou sprints.

FAQ

Quelle durée de sprint pour une petite équipe ?

Deux semaines conviennent à la plupart des petites équipes produit : assez pour terminer quelque chose qui mérite une démo, assez court pour qu'un mauvais plan coûte peu. Une semaine va aux équipes qui livrent chaque jour ; trois ou quatre au travail très exploratoire. Le Guide Scrum plafonne les sprints à un mois.

Une petite équipe a-t-elle besoin d'un daily ?

En général pas sous forme de réunion. Un point écrit dans un fil de chat donne la même information en quelques minutes sans casser la concentration de personne. Gardez un daily en direct seulement si les blocages restent tus à l'écrit.

Une équipe de cinq doit-elle utiliser des story points ?

En général non. Compter les tickets terminés donne une fourchette de capacité suffisante pour planifier, sans réunion d'estimation. Les points aident quand il faut prévoir des dates de livraison pour des clients ou quand la taille des tickets varie trop pour les découper.

Que faire du travail inachevé à la fin d'un sprint ?

Fixez une règle une fois, puis appliquez-la. Soit tout l'inachevé passe au sprint suivant, comme le fait Linear automatiquement, soit chaque élément est revu et envoyé au sprint suivant ou au backlog, comme Jira vous demande de choisir. Surveillez tout ticket reporté deux fois.

Scrum convient-il à une équipe de cinq ?

La taille d'équipe du Guide Scrum, dix personnes ou moins, inclut cinq personnes, donc oui en principe. En pratique, la plupart des équipes de cinq gardent la durée fixe, l'objectif et la revue de Scrum, et remplacent le daily et la rétrospective complète par des versions plus légères.

Étape suivante

Copiez le modèle de planification de sprint pour votre prochaine planification, et lisez l'entrée sprint du glossaire pour retrouver les termes Scrum au même endroit.