Mon article en bref
Le sprint goal, ou objectif de sprint, est l’objectif unique que l’équipe Scrum s’engage à atteindre pendant l’itération. Il répond à la question « pourquoi ce sprint ? » et non « que fait-on ce sprint ? ». Ce n’est pas une bonne pratique optionnelle : c’est un engagement formel du framework.
Voici les points essentiels à retenir :
- Définition : l’objectif unique du sprint, formulé en termes de valeur et non de liste de tâches.
- Statut : le Guide Scrum en fait l’engagement attaché au sprint backlog — chaque sprint doit en avoir un.
- Qui le définit : toute la Scrum Team pendant le sprint planning, Product Owner et Developers ensemble.
- Un seul : deux objectifs dans un sprint équivalent à aucun objectif.
- Il ne change pas en cours de sprint, mais le périmètre pour l’atteindre peut être renégocié.
- Bon test : si l’objectif reste vrai en supprimant la moitié des items, il est bien formulé.
Le sprint goal, ou objectif de sprint en français, est la description concise et unique de ce que l’équipe Scrum cherche à accomplir au cours d’un sprint. Il ne liste pas le travail à faire : il énonce la raison pour laquelle ce travail est entrepris, et donne à l’équipe un cap commun pour toutes les décisions qu’elle prendra pendant l’itération.
C’est l’élément de Scrum le plus souvent bâclé — réduit à un intitulé recopié depuis le premier ticket, quand il n’est pas purement absent. Voyons ce qu’il est exactement, le statut particulier que lui donne le framework, comment le formuler, et à quoi ressemble un objectif de sprint réussi.
Sommaire
Qu’est-ce qu’un sprint goal ? Définition
Le sprint goal est l’objectif unique du sprint. Il est décidé pendant le sprint planning et reste valable jusqu’à la fin de l’itération. Sa fonction est de transformer une sélection d’éléments de backlog en une intention cohérente : sans lui, un sprint n’est qu’un lot de tickets exécutés en parallèle.
La distinction fondatrice se joue sur une question. Un sprint goal ne répond pas à « que faisons-nous ce sprint ? » — c’est le rôle du backlog. Il répond à « pourquoi faisons-nous ce sprint ? ». Reformulé en valeur, il devient exploitable pour arbitrer : face à un imprévu, l’équipe sait ce qu’elle peut sacrifier et ce qu’elle doit préserver.
Un seul objectif, pas une liste
Le mot unique compte. Un sprint qui poursuit trois objectifs n’en poursuit aucun : à la première tension, l’équipe n’a plus de critère pour trancher. Si le contenu du sprint ne se laisse pas résumer en une intention, c’est généralement le signe que la sélection est hétéroclite — et le problème est alors dans le sprint planning, pas dans la formulation de l’objectif.
Qui définit le sprint goal ?
Toute la Scrum Team, pendant le sprint planning. Le Product Owner apporte l’intention métier et la priorité ; les Developers confrontent cette intention à ce qui est réalisable dans le temps imparti. L’objectif se construit dans cette confrontation. Ce n’est ni une commande descendante du Product Owner, ni une décision du Scrum Master, dont le rôle est de faciliter la discussion.
Un engagement du framework, pas une bonne pratique
Voici ce que beaucoup d’équipes ignorent, et qui change le statut de l’exercice. Le Guide Scrum 2020 associe à chacun des trois artefacts un engagement destiné à en renforcer la transparence :
| Artefact | Engagement associé |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
Le sprint goal n’est donc pas un supplément facultatif : c’est l’engagement qui donne son sens au sprint backlog. Une équipe qui n’en formule pas laisse un artefact du framework sans son engagement — ce qui, contrairement aux story points ou à la vélocité (que le Guide ne mentionne jamais), constitue un véritable écart au cadre.
Story points et vélocité sont des pratiques ajoutées à Scrum ; le sprint goal, lui, fait partie du framework.
L’objectif ne change pas, le périmètre oui
Conséquence directe et souvent mal comprise : pendant le sprint, le sprint goal reste stable, mais le périmètre nécessaire pour l’atteindre peut être renégocié avec le Product Owner. C’est exactement l’inverse du réflexe habituel, qui consiste à tenir la liste des tickets coûte que coûte en perdant de vue l’intention. Ici, l’objectif est l’invariant et les tickets sont la variable d’ajustement.
Comment formuler un bon sprint goal ?
Un sprint goal utile tient en une ou deux phrases, se comprend sans contexte technique, et énonce un résultat plutôt qu’une activité. Quatre étapes suffisent à le construite pendant le sprint planning :
- Partir du besoin, pas du backlog — le Product Owner expose le problème utilisateur ou métier le plus pressant, avant toute sélection d’éléments.
- Énoncer le résultat visé — « permettre à un client de retrouver sa commande sans contacter le support » plutôt que « développer l’écran de suivi ».
- Vérifier qu’il est observable — l’équipe doit pouvoir dire à la sprint review, sans débat, si l’objectif est atteint ou non.
- Sélectionner les éléments ensuite — le contenu du sprint découle de l’objectif, jamais l’inverse.
💡 Le test de la moitié — supprimez mentalement la moitié des éléments du sprint. Si l’objectif reste atteignable et pertinent, il est bien formulé : il porte une intention. S’il s’écroule, c’est qu’il n’était qu’un résumé de la liste des tickets.
Le sprint goal gagne aussi à être affiché et relu au daily scrum. C’est là qu’il prend toute son utilité : la question du jour n’est plus « où en es-tu de ton ticket ? » mais « qu’est-ce qui nous rapproche de l’objectif aujourd’hui ? ».
Quatre pièges de formulation
Les objectifs ratés se rangent presque tous dans l’une de ces quatre catégories. Les reconnaître pendant le sprint planning fait gagner un sprint entier :
- L’inventaire déguisé — « livrer les fonctionnalités A, B et C ». Aucun arbitrage possible : si B déraille, l’objectif est perdu sans qu’on sache quoi protéger.
- Le vœu pieux — « améliorer l’expérience utilisateur ». Ni seuil, ni périmètre : impossible de conclure à la review.
- L’objectif technique sans bénéficiaire — « migrer la base de données ». La migration peut être le moyen, elle ne dit pas ce qu’elle rend possible.
- L’objectif hors de portée — un résultat qui dépend d’une équipe tierce ou d’une décision extérieure. L’équipe s’engage alors sur ce qu’elle ne maîtrise pas.
Le vocabulaire compte aussi. La terminologie française est stabilisée : l’Office québécois de la langue française retient objectif de sprint comme équivalent officiel de sprint goal. Les deux formes circulent dans les équipes francophones, et l’anglicisme reste largement dominant à l’oral.
En vidéo : à quel moment définir l’objectif de sprint (chaîne Scrum Life).
Exemples et contre-exemples de sprint goals
La différence entre un objectif de sprint et un intitulé de lot se voit mieux sur des cas concrets. Les formulations de gauche portent une intention ; celles de droite ne sont que des inventaires déguisés.
- Bon : « Permettre à un client de suivre sa commande en autonomie, pour réduire les sollicitations du support. » → un résultat, une raison, vérifiable.
- Mauvais : « Terminer les tickets 412, 418 et 431. » → une liste, aucune intention, rien à arbitrer en cas d’imprévu.
- Bon : « Ramener le temps de déploiement sous cinq minutes pour rendre possible une mise en production quotidienne. » → mesurable, avec le bénéfice explicite.
- Mauvais : « Améliorer la performance. » → ni périmètre, ni seuil, ni moyen de conclure à la review.
- Bon : « Valider auprès de dix utilisateurs que le nouveau parcours d’inscription est compris sans aide. » → un objectif d’apprentissage, parfaitement légitime.
Le troisième exemple mérite d’être souligné : un sprint goal n’est pas obligatoirement une livraison. Un sprint de discovery, dont l’objectif est de réduire une incertitude, se formule très bien ainsi — et c’est souvent le sprint le plus rentable du trimestre.
FAQ — Tout savoir sur le sprint goal
Qui définit le sprint goal en Scrum ?
Toute la Scrum Team, pendant le sprint planning. Le Product Owner apporte l’intention métier, les Developers confrontent cette intention au réalisable. Le Scrum Master facilite la discussion mais ne décide pas de l’objectif.
Peut-on avoir plusieurs sprint goals ?
Non. Le Guide Scrum prévoit un objectif unique par sprint. Poursuivre plusieurs objectifs prive l’équipe du critère d’arbitrage dont elle a besoin en cas d’imprévu. Si le contenu du sprint ne se résume pas en une intention, c’est la sélection qu’il faut revoir.
Le sprint goal peut-il changer en cours de sprint ?
Non, il reste stable pendant toute l’itération. En revanche, le périmètre de travail nécessaire pour l’atteindre peut être renégocié avec le Product Owner. C’est l’objectif qui est l’invariant, pas la liste des éléments du sprint backlog.
Que se passe-t-il si le sprint goal n’est pas atteint ?
Rien de punitif : le sprint se termine normalement et le sujet est examiné en sprint review puis en rétrospective. Un objectif manqué est une information sur la façon dont l’équipe planifie ou estime, pas une faute à sanctionner.
Quelle différence entre sprint goal et product goal ?
Le product goal est l’objectif de moyen terme du produit, attaché au product backlog. Le sprint goal est l’objectif d’une seule itération, attaché au sprint backlog. Chaque sprint goal doit contribuer au product goal, qui lui survit à de nombreux sprints.
Le sprint goal est-il obligatoire ?
Oui. Contrairement aux story points ou à la vélocité, qui sont des pratiques ajoutées au framework, le sprint goal figure dans le Guide Scrum comme l’engagement attaché au sprint backlog. Chaque sprint doit en avoir un.
