Cycles ou sprints : ce qui change vraiment, et lequel une petite équipe devrait adopter
Cycles et sprints sont des périodes fixes pour du travail planifié. Les cycles retirent le cérémonial de Scrum.
Sur cette page
Un sprint et un cycle sont fondamentalement la même chose : une période courte et fixe pendant laquelle une équipe s'engage sur un ensemble de travail choisi. La différence tient à ce qui les entoure. Le sprint vient de Scrum et transporte ses événements, ses rôles et l'habitude d'estimer en points. Le cycle, terme popularisé par Linear, garde la période et laisse tomber presque tout le reste : le travail inachevé est reporté automatiquement, les temps de récupération sont intégrés, et la vélocité est optionnelle ou absente.
Si vous avez déjà débattu pour savoir s'il fallait appeler la chose sprint ou cycle, ce débat portait en général sur le cérémonial, pas sur le calendrier. Cet article explique d'où viennent les deux termes, ce que chaque outil fait réellement quand le temps est écoulé, et comment nous avons tranché pour notre propre équipe.
D'où viennent les sprints
Le sprint est un concept Scrum. Le Guide Scrum définit les sprints comme des événements de durée fixe d'un mois ou moins, précise qu'un nouveau sprint commence immédiatement après la fin du précédent, et donne à chaque sprint un objectif unique, le Sprint Goal. Autour de la période, Scrum place quatre événements : la planification, la mêlée quotidienne, la revue et la rétrospective.
Rien de cela n'est optionnel dans Scrum tel qu'écrit. Le Guide précise aussi que les pratiques de prévision comme les burn-downs, burn-ups et flux cumulés sont utiles mais ne remplacent pas l'empirisme ; ce sont des instruments, pas la méthode.
Jira est l'outil où la plupart des gens rencontrent les sprints. Le conseil d'Atlassian aux équipes qui débutent est un sprint fixe de deux semaines. Quand vous cliquez sur « Terminer le sprint » dans Jira avec du travail encore ouvert, vous choisissez où il va : le backlog, n'importe quel sprint futur déjà créé, ou un nouveau sprint créé sur-le-champ. La documentation Jira décrit ces trois options ; la décision vous revient à chaque fois.
D'où viennent les cycles
« Cycle » comme terme produit s'est répandu grâce à Linear, qui a choisi ce mot pour signaler une version plus légère de la même idée. La documentation des cycles de Linear en décrit la forme : l'équipe choisit une durée, d'une à huit semaines, et un jour de départ, et les cycles se répètent ensuite selon ce calendrier. L'équipe peut ajouter une période de récupération après chaque cycle, un intervalle pour la dette technique et la planification, et aucune issue ne peut être affectée à une récupération.
Le comportement en fin de cycle est la plus grande différence pratique avec un sprint. Dans Linear, les issues ouvertes passent automatiquement au cycle suivant, et il n'existe aucun moyen de conserver des issues inachevées dans un cycle clos. Là où Jira vous demande où doit aller le travail inachevé, Linear l'a déjà déplacé. Linear propose aussi d'ajouter automatiquement au cycle en cours les issues démarrées, pour que le travail commencé hors du plan soit capturé plutôt que perdu.
La planification de capacité existe, mais elle est discrète. Pour un cycle pas encore démarré, Linear estime la capacité à partir du nombre d'issues ou de points d'estimation terminés sur les trois derniers cycles achevés. Vous pouvez utiliser des points si vous le souhaitez ; beaucoup d'équipes comptent plutôt les issues. Linear permet de créer jusqu'à quinze cycles futurs.
Cycles ou sprints : la comparaison
Le tableau compare le concept tel que Scrum le définit, tel que Jira l'implémente, et tel que Linear et Atrix implémentent les cycles, en octobre 2026.
| Sprint Scrum | Sprint Jira | Cycle Linear | Cycle Atrix | |
|---|---|---|---|---|
| Durée | Un mois ou moins, fixe | Au choix ; deux semaines recommandées | 1 à 8 semaines, fixe par équipe | 1 à 4 semaines, avec un objectif |
| Objectif | Obligatoire (Sprint Goal) | Champ optionnel | Optionnel | Défini à la création du cycle |
| Travail inachevé à la fin | Retourne au backlog produit pour replanification | Vous choisissez : backlog, sprint futur ou nouveau sprint | Reporté automatiquement au cycle suivant | Reporté au cycle suivant ou renvoyé au backlog |
| Intervalle entre périodes | Aucun ; le sprint suivant commence immédiatement | Aucun intégré | Récupération optionnelle ; aucune issue affectable | Aucun intégré |
| Estimation | Non prescrite | Points de récit courants | Points d'estimation optionnels | Aucune ; pas de points de récit |
| Vélocité | Pas un terme Scrum | Graphique de vélocité | Capacité d'après les trois derniers cycles | Non suivie ; le burndown compte les issues |
| Cérémonial | Planification, mêlée quotidienne, revue, rétrospective | Ce que l'équipe ajoute | Ce que l'équipe ajoute | Ce que l'équipe ajoute |
Lisez une ligne de gauche à droite et le schéma est clair. Scrum définit la méthode ; Jira vous donne les champs pour l'appliquer et vous laisse les décisions ; les outils à cycles prennent les décisions à votre place et retirent les champs sur lesquels vous pourriez débattre.
Les trois différences qui comptent au quotidien
Ce qu'il advient du travail inachevé. Dans un outil à sprints, clore la période est un petit cérémonial avec une décision attachée. Dans un outil à cycles, c'est une date qui passe. Le report automatique signifie que rien n'est perdu par accident, et qu'une équipe qui surplanifie verra les mêmes issues glisser trois cycles de suite. Cette visibilité est le but. Un cycle qui reporte toujours le même travail est un problème de planification, pas d'outil.
Estimer ou non. Les points de récit servent à prévoir ce qu'une équipe peut absorber. Les outils à cycles les traitent comme optionnels, et certains, dont Atrix, n'en proposent pas du tout. Compter les issues est plus grossier mais plus difficile à manipuler, et pour une équipe de cinq, c'est en général suffisant. Le compromis est honnête : s'il faut dire à un client combien de semaines prendra un périmètre, points et vélocité donnent un chiffre défendable ; le nombre d'issues en donne un approximatif.
La quantité de cérémonial attachée. Un sprint implique quatre réunions. Un cycle n'en implique aucune. La plupart des petites équipes qui fonctionnent en cycles font quand même une courte planification et une forme de revue, mais elles le choisissent, et elles peuvent sauter la rétrospective lors d'une quinzaine calme sans avoir le sentiment d'avoir cassé la méthode.
Récupération et question de cadence
Le « un nouveau sprint commence immédiatement » de Scrum est délibéré : il garde un rythme stable et empêche les intervalles entre sprints d'avaler une semaine. La récupération de Linear est le choix inverse : une pause intégrée où aucune issue ne peut être affectée, destinée à la dette et à la planification.
D'après notre expérience, la récupération fonctionne quand elle est courte et protégée. Une semaine après un cycle de six donne aux gens la place de corriger ce qui les agaçait et de planifier correctement le bloc suivant. Une récupération qui devient « la semaine où personne ne sait quoi faire » est pire que pas de récupération. Si votre équipe compte deux ou trois personnes, vous n'en avez probablement pas besoin ; la fin d'un cycle et le début du suivant peuvent tenir dans le même après-midi.
Ce que nous pratiquons, et pourquoi
Nous fonctionnons en cycles de deux semaines dans Atrix, notre propre espace de travail, pour le travail produit, et nous avons choisi les cycles plutôt que les sprints pour une raison sans rapport avec le vocabulaire. Avec quatre à six personnes par produit, le temps passé sur les points et la vélocité n'améliorait pas nos prévisions. Compter les issues, avec un objectif par cycle et un burndown des issues ouvertes, nous disait ce que nous avions besoin de savoir : allons-nous atteindre l'objectif, ou non ?
Ce qu'Atrix vous donne, dit simplement : des cycles d'une à quatre semaines par produit, chacun avec un objectif ; vous planifiez des issues du backlog dans un cycle ; le burndown compte les issues ouvertes ; quand vous terminez un cycle, l'inachevé passe au cycle suivant ou retourne au backlog. Les étiquettes colorées et les jalons sont à côté. Ce qu'il ne vous donne pas : points de récit, graphiques de vélocité ou réglage de récupération. Si votre processus dépend de l'un d'eux, Jira ou Linear conviennent mieux, et la page de gestion de projet le dit sans détour.
Comment choisir pour votre équipe
- Comptez les personnes et les clients. Deux à huit personnes sur un produit : des cycles comptés en issues suffisent. Une équipe qui doit donner des dates de livraison à des clients à partir de son débit historique : des sprints avec points, ou des cycles avec points d'estimation dans un outil qui en propose.
- Choisissez une durée et gardez-la. Deux semaines est le défaut courant pour une bonne raison ; une semaine convient à une équipe qui livre chaque jour, quatre semaines à un travail riche en recherche. Changer la durée à chaque cycle détruit la comparaison entre eux.
- Écrivez un objectif. Quel que soit le nom que lui donne l'outil, un cycle avec une phrase d'intention est plus facile à planifier et à juger qu'une liste d'issues.
- Fixez la règle de report une fois pour toutes. Report automatique ou décision délibérée à la clôture. Les deux marchent. Changer d'avis à chaque fois est ce qui fait disparaître du travail.
- Gardez la revue, supprimez ce que vous n'utilisez pas. Un coup d'œil de quinze minutes sur ce qui a été livré vaut la peine même dans le processus le plus léger. Une rétrospective à chaque cycle ne vaut la peine que si elle change quelque chose.
Si vous voulez un modèle pour démarrer, le modèle de planification de sprint couvre un objectif, la capacité en issues et la liste de report, et convient aux deux mots.
FAQ
Un cycle, est-ce la même chose qu'un sprint ?
Les deux sont des périodes fixes pour du travail planifié, donc au quotidien ils sont interchangeables. La différence tient à ce qui y est attaché : un sprint transporte les événements de Scrum et en général des points et une vélocité ; un cycle, dans des outils comme Linear et Atrix, garde la période, reporte l'inachevé automatiquement et traite l'estimation comme optionnelle.
Pourquoi Linear les a-t-il appelés cycles plutôt que sprints ?
Linear utilise ce mot pour marquer une version plus légère : durée fixe, report automatique, récupérations optionnelles et aucune obligation d'estimer. Le terme éloigne la pratique du cérémonial complet de Scrum sans changer l'idée de fond de travailler par périodes courtes et fixes.
Que deviennent les issues inachevées à la fin d'un cycle ?
Dans Linear, les issues ouvertes passent automatiquement au cycle suivant ; les inachevées ne peuvent pas rester dans un cycle clos. Dans Atrix, le travail inachevé passe au cycle suivant ou retourne au backlog quand vous terminez le cycle. Dans Jira, vous choisissez à la clôture entre le backlog, un sprint futur ou un nouveau sprint.
Qu'est-ce qu'une récupération dans la planification par cycles ?
Une récupération est un intervalle optionnel après un cycle, utilisé pour la dette technique, la correction de bugs et la planification du cycle suivant. Dans Linear, aucune issue ne peut être affectée à une récupération. Scrum n'a pas d'équivalent ; le Guide Scrum dit qu'un nouveau sprint commence immédiatement après le précédent.
Les cycles utilisent-ils des points de récit ou une vélocité ?
Pas nécessairement. Linear prend en charge des points d'estimation optionnels et dérive la capacité des trois derniers cycles achevés, par issues ou par points. Atrix n'utilise ni points de récit ni vélocité ; son burndown compte les issues ouvertes. Jira propose les deux en standard.
Combien de temps doit durer un cycle ou un sprint ?
Le Guide Scrum plafonne les sprints à un mois. Atlassian recommande deux semaines aux équipes qui débutent. Linear permet d'une à huit semaines et Atrix d'une à quatre. Deux semaines est le choix le plus courant pour les petites équipes produit ; l'important est de fixer la durée et de la garder.
Prochaine étape
Lisez l'entrée sprint du glossaire pour la définition Scrum et ses événements, puis montez un premier cycle avec le modèle de planification de sprint. Si vous voulez des cycles avec un objectif et un burndown en nombre d'issues, et rien d'autre, c'est ce que fait la gestion de projet dans Atrix.