Qu'est-ce qu'un sprint ?
Un sprint est une itération de travail à durée fixe, généralement d'une à quatre semaines, au terme de laquelle une équipe agile livre un incrément utilisable du produit. Dans Scrum, c'est l'unité de rythme : chaque sprint poursuit un objectif et enchaîne planification, mêlées quotidiennes, revue et rétrospective.
Au lieu de tout planifier au départ et de livrer un an plus tard, on découpe le projet en cycles courts et répétés. Chaque cycle, ou sprint, produit un résultat que l'on peut montrer, tester et critiquer. On apprend, on ajuste, on repart. Ce battement régulier, bien plus que le vocabulaire, est ce qui distingue l'approche agile d'une conduite de projet classique.
Le mot qui compte est itération. Un sprint est une boucle complète, du choix du travail à la livraison d'un morceau fonctionnel, que l'on répète à l'identique dans sa forme ; ni une phase parmi d'autres, ni un simple délai. La durée ne change pas, le déroulé non plus. Seul le contenu évolue d'un sprint à l'autre, en fonction de ce que l'équipe a appris.
Durée et objectif d'un sprint
Un sprint dure entre une et quatre semaines, et cette durée reste identique d'un sprint à l'autre. Deux semaines est le rythme le plus courant. Chaque sprint poursuit un objectif de sprint, le résultat concret que l'équipe s'engage à atteindre, qui donne une direction commune et un critère de réussite.
La durée n'est pas un détail. Un sprint trop long fait perdre le bénéfice du rythme : les retours arrivent tard, le cap dérive, on retombe dans les travers du projet fleuve. Un sprint trop court noie l'équipe sous les rituels et ne laisse pas le temps de livrer quelque chose de significatif. Deux semaines est un bon compromis pour la plupart des projets numériques : assez court pour corriger vite, assez long pour produire de la valeur visible.
La règle la plus importante tient en une phrase : on ne rallonge jamais un sprint en cours. Si le travail prévu n'est pas terminé, la durée ne bouge pas ; le périmètre, oui. Ce qui n'est pas fini retourne dans la liste des priorités et sera peut-être repris au sprint suivant. Cette discipline protège le rythme et rend la vélocité, la quantité de travail achevée en moyenne par sprint, réellement mesurable.
L'objectif de sprint (ou sprint goal) est le second pilier. Un bon objectif décrit une valeur livrée, pas une simple liste de tâches. Par exemple « permettre à un utilisateur de finaliser sa commande » plutôt que « coder l'écran de paiement ». Cet objectif sert de boussole : quand un imprévu surgit en cours de route, l'équipe sait ce qu'elle doit protéger en priorité et ce qu'elle peut laisser de côté.
Le déroulé d'un sprint : les quatre événements
Un sprint s'articule autour de quatre événements : la planification, qui l'ouvre et fixe l'objectif ; la mêlée quotidienne, un point court chaque jour ; la revue de sprint, où l'équipe présente l'incrément aux parties prenantes ; et la rétrospective, où elle améliore sa façon de travailler. Ces rituels donnent au sprint sa structure et son rythme.
Ces événements ne sont pas de la bureaucratie. À chacun sa question : ce qu'on engage, où l'on en est le jour même, ce qui a été livré, et ce qu'on change ensuite. Ils s'enchaînent ainsi, de l'ouverture à la clôture.
- La planification (sprint planning). Le sprint s'ouvre par une réunion où l'équipe et le product owner examinent le haut de la liste des priorités, choisissent ce qui entre dans le sprint et formulent l'objectif. Ce qui est retenu constitue le sprint backlog. C'est le moment où l'engagement se prend.
- La mêlée quotidienne (daily). Chaque jour, un point de quinze minutes, debout de préférence, où l'équipe se synchronise : ce qui avance, ce qui bloque, ce qui est prévu ensuite. C'est une coordination entre pairs pour ajuster le cap au jour le jour, et non un compte rendu à un chef.
- La revue de sprint (sprint review). À la fin du sprint, l'équipe montre l'incrément aux parties prenantes et recueille leurs retours. C'est la confrontation au réel : on voit ce qui fonctionne, ce qui manque, et on nourrit la suite du travail avec ces observations.
- La rétrospective. Juste après la revue, l'équipe examine sa propre façon de travailler et décide d'une ou deux améliorations concrètes pour le sprint suivant. C'est le moteur d'amélioration continue, et le rituel que l'on sacrifie le plus souvent à tort.
Entre la planification et la revue, il y a le travail lui-même : l'équipe construit, teste, ajuste, rythmée par la mêlée quotidienne. Ce cœur du sprint n'a rien d'un événement formel : c'est la durée pendant laquelle l'incrément prend forme.
Le sprint backlog : le contenu du sprint
Le sprint backlog est la liste des éléments que l'équipe s'engage à réaliser pendant le sprint en cours. Il est sélectionné dans le product backlog lors de la planification, en fonction de l'objectif du sprint et de la capacité de l'équipe. Le sprint est le contenant temporel, le sprint backlog en est le contenu.
C'est une distinction que je précise souvent, car les deux termes se confondent facilement. Le sprint est une période. Le sprint backlog est une liste de travail. On remplit ce sprint backlog au moment de la planification, en tirant du haut du product backlog les éléments les plus prioritaires que l'équipe pense pouvoir terminer dans le temps imparti.
Ce backlog du sprint appartient à l'équipe de développement, qui décide elle-même comment s'organiser pour l'accomplir. Il n'est pas gravé dans le marbre : l'équipe peut le réorganiser en cours de route, tant qu'elle ne perd pas de vue l'objectif. Pour bien comprendre comment on alimente et priorise le vivier de travail en amont, je détaille ce mécanisme dans mon guide du backlog produit, la pièce dont dépend directement la qualité de chaque sprint.
Ce qui fait échouer un sprint
Un sprint échoue rarement à cause de la technique. Il échoue quand son objectif est flou, quand le sprint backlog est surchargé au départ, quand les priorités changent en plein milieu ou quand la rétrospective est expédiée. Le cadre reste alors intact en apparence, mais il ne produit plus de valeur : c'est un sprint de façade.
Sur le terrain, les mêmes causes reviennent d'un projet à l'autre. Les repérer tôt évite de gaspiller des semaines entières :
- Un objectif absent ou vague. Sans sprint goal clair, l'équipe empile des tâches sans direction commune. On finit le sprint sans savoir si on a réussi, parce qu'il n'y avait pas de critère de réussite.
- Un sprint backlog trop chargé. On promet trop pour faire plaisir, puis on court après le temps. La qualité baisse, le stress monte, et on prend l'habitude de reporter au sprint suivant.
- Des priorités qui changent en cours de route. Une direction qui réoriente le travail au milieu du sprint casse l'engagement et la mesure. Le sprint doit être protégé une fois lancé, sinon il ne veut plus rien dire.
- Une rétrospective sacrifiée. Quand on supprime ce rituel « pour gagner du temps », l'équipe répète les mêmes erreurs. Le sprint perd sa capacité à s'améliorer, qui est pourtant sa raison d'être.
- Une définition de terminé floue. Sans critère clair de ce que signifie « fini », l'incrément livré n'est pas vraiment utilisable. On accumule une dette invisible qui ressort plus tard.
Le point commun de ces échecs, c'est qu'on garde la forme et qu'on perd l'intention. Un sprint n'a de valeur que s'il livre quelque chose de réel et que l'équipe apprend de ce qu'elle a livré. Le reste n'est que du théâtre.
Sprint et Scrum : comment ils s'articulent
Le sprint est le cœur de Scrum, le framework agile le plus répandu. Scrum définit trois rôles, quatre événements et trois artefacts, et le sprint est l'événement qui contient tous les autres. On ne fait donc pas de Scrum sans sprints : c'est l'unité de temps autour de laquelle tout le cadre s'organise.
Le sprint n'existe pas isolément. Il prend son sens à l'intérieur d'un cadre plus large qui définit qui fait quoi (le product owner, le scrum master, l'équipe de développement) et sur quels supports le travail devient visible (product backlog, sprint backlog, incrément). Le sprint, lui, est le battement de cœur qui met tout cela en mouvement de façon cadencée. Pour voir comment ces rôles, ces événements et ces artefacts s'imbriquent, je renvoie à mon guide complet du framework Scrum.
Il existe d'autres façons de travailler en agile qui ne reposent pas sur le sprint. Le Kanban, par exemple, gère un flux continu de tâches sans itérations imposées : idéal quand les demandes arrivent en permanence, comme en maintenance ou en support. Le sprint est donc un choix, pas une obligation de l'agilité. On l'adopte quand le travail se planifie par lots et se livre par cycles, ce qui est le cas de la plupart des projets de développement produit.
Comment je fais tenir un sprint sur le terrain.
Ce qui fait tenir un sprint, c'est un objectif clair et un périmètre honnête, bien avant le respect scrupuleux du rituel. Sur mes projets, je passe du temps à formuler un vrai sprint goal avec l'équipe, puis je protège le sprint une fois lancé, y compris contre les demandes de dernière minute de la direction. Ancien développeur, je connais le coût réel d'une interruption ; pilote de projet, je sais dire non au bon moment. C'est ce double regard qui évite les sprints de façade et fait que chaque itération produit vraiment quelque chose.
Questions fréquentes
À propos de l'auteur
Laurent Tulpan
Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote des équipes projet en agile comme en cycle en V pour des grands comptes et des PME (TF1, SFR, Orange, SNCF), en faisant le lien entre les équipes techniques et la direction. Découvrir son approche.
À lire ensuite
La gestion de projet digital
Le guide de référence : méthodes, rôles, pilotage et réussite d'un projet.
Scrum expliqué simplement
Le cadre agile dont le sprint est le cœur : rôles, événements et artefacts.
Le backlog produit
La liste priorisée dans laquelle chaque sprint puise son travail.
La méthode agile expliquée
L'état d'esprit et les valeurs dont le sprint est l'incarnation concrète.