15 exemples de Sprint Goals avant / après corrigés
Découvrez pourquoi certains Sprint Goals motivent toute une équipe tandis que d'autres deviennent de simples listes de tâches.
Comprendre le Sprint GoalCet article ne redéfinit pas le Sprint Goal — pour la définition, son rôle dans Scrum, son lien avec le Sprint Backlog, le Scrum Guide 2020 et les pièges PSM I, gardez le pilier Sprint Goal sous la main. Ici, on prend le problème par l'autre bout : comment écrire un excellent Sprint Goal, en partant de 15 exemples réels commentés, secteur par secteur.
1. Pourquoi tant de Sprint Goals échouent
Dans la majorité des équipes rencontrées, ce qui est appelé « Sprint Goal » n'en est pas un. C'est souvent une liste de User Stories, un objectif technique, une refonte sans utilisateur, voire un simple « finir le Sprint ». Résultat : le Sprint Backlog perd sa cohérence, les Developers subissent au lieu de s'engager, et la Sprint Review se transforme en démonstration de tickets terminés.
Les causes récurrentes :
- Liste de User Stories — « Faire les US 12 à 25 » n'engage sur rien de plus que du travail.
- Objectif technique — « Créer une API », « migrer le back », « refactorer le module X ».
- Absence de valeur — Aucun utilisateur, aucun bénéfice, aucune capacité livrée.
- Objectif trop vague — « Améliorer », « optimiser », « avancer sur ».
- Objectif impossible à atteindre — Trop gros pour le Sprint, ou totalement hors de contrôle de l'équipe.
Selon le Scrum Guide 2020, le Sprint Goal est l'unique objectif du Sprint et l'engagement du Sprint Backlog. Ce n'est ni un lot de tickets, ni une refonte technique, ni un slogan. Les 15 exemples qui suivent rendent cette différence tangible.
2. 15 cas pratiques de Sprint Goals — analyse commentée
Chaque étude de cas suit la même structure : contexte, mauvais Sprint Goal formulé par l'équipe, analyse, version corrigée, justification Scrum Guide et enseignement PSM I. Les secteurs sont variés pour couvrir les cas rencontrés en entreprise et en préparation certification.
Suite SaaS de gestion de projet. Sprint dédié à l'onboarding.
« Livrer les US 42 à 55 et corriger les 12 bugs remontés. »
Liste de tickets déguisée en objectif. Aucune valeur, aucun résultat, aucune flexibilité. Si un ticket saute, l'équipe pense avoir échoué.
« « Permettre à un nouvel utilisateur d'être opérationnel en moins de 10 minutes après inscription. » »
Le Scrum Guide 2020 précise que le Sprint Goal est l'unique objectif du Sprint et l'engagement du Sprint Backlog — pas la somme de ses items.
Un Sprint Goal décrit un résultat utilisateur atteignable en un Sprint, pas un lot de tâches.
App mobile bancaire. Sprint centré sur la souscription en ligne.
« Finir le module d'ouverture de compte. »
« Finir » n'est pas un résultat, c'est un aveu d'incertitude. Le module peut être livré et… ne servir à rien.
« « Permettre à un nouveau client d'ouvrir un compte 100 % en ligne, sans passer par une agence. » »
Le Sprint Goal apporte de la cohérence et de la flexibilité au travail : les Developers peuvent adapter le Sprint Backlog tant que l'objectif est atteint.
Un Sprint Goal formule une capacité nouvelle offerte à l'utilisateur, pas la fin d'une checklist.
Déclaration de sinistre auto. Sprint sur le parcours photo.
« Intégrer l'API du prestataire d'analyse d'images. »
Objectif technique sans utilisateur. L'API peut être intégrée sans que personne ne puisse déclarer un sinistre plus vite.
« « Réduire à moins de 3 minutes le temps nécessaire pour déclarer un sinistre auto avec photos depuis un mobile. » »
Le Sprint Goal doit apporter de la valeur, pas décrire un moyen technique. Il oriente les décisions de conception.
Un Sprint Goal formulé en résultat métier tranche mille micro-décisions techniques.
MES pour ligne d'assemblage. Sprint sur la remontée temps réel.
« Refactorer le module de collecte capteurs. »
Refactor = travail invisible pour le métier. Ce n'est pas un Sprint Goal, c'est de la dette technique déguisée.
« « Permettre au chef d'atelier de voir en temps réel l'état d'avancement de chaque poste d'assemblage. » »
Le Sprint Goal doit être compréhensible par la Scrum Team et les parties prenantes. Un chef d'atelier doit pouvoir dire s'il est atteint.
Un vrai Sprint Goal se raconte à un stakeholder en une phrase, sans jargon.
Portail patient hospitalier. Sprint sur la prise de RDV.
« Faire les 8 écrans Figma validés. »
Livrer des écrans ne garantit rien. Le patient peut ne toujours pas réussir à prendre RDV. Output ≠ outcome.
« « Permettre à un patient de prendre un rendez-vous en 3 clics depuis son espace personnel. » »
Le Sprint Goal exprime la valeur livrée à la fin du Sprint via un Increment potentiellement utilisable.
Le nombre d'écrans n'est jamais un Sprint Goal. La capacité utilisateur, si.
App de transport urbain. Sprint sur l'achat de titres.
« Sortir la V2 de l'app. »
« V2 » ne veut rien dire côté utilisateur. On peut sortir une V2 vide de valeur ou repousser une V2 utile.
« « Permettre à un usager d'acheter et valider un titre de transport en moins de 20 secondes depuis l'app. » »
Le Sprint Goal doit être atteignable dans un seul Sprint et rester stable — la portée peut négocier, le Goal non.
Un Sprint Goal ne se mesure jamais en numéros de version.
Marketplace mode. Sprint sur le tunnel de commande.
« Améliorer le checkout. »
« Améliorer » est un mot vide. Quel utilisateur ? Quelle amélioration ? Quel résultat inspectable en Sprint Review ?
« « Faire passer le taux de complétion du panier de 62 % à 75 % pour les acheteurs mobile. » »
Le Sprint Goal fournit un critère d'inspection en Sprint Review : sans mesure, l'inspection devient de l'auto-évaluation.
Un Sprint Goal peut chiffrer un résultat — mais toujours au bénéfice d'un utilisateur nommé.
API de paiement pour partenaires. Sprint sur l'onboarding développeur.
« Créer une API REST pour les remboursements. »
Un endpoint n'est pas un Sprint Goal. Un partenaire peut avoir l'endpoint et rester incapable de l'intégrer.
« « Permettre à un développeur partenaire d'intégrer un remboursement de bout en bout en moins d'une heure. » »
Sur un produit API, l'« utilisateur » est le développeur intégrateur. Le Sprint Goal doit exprimer sa capacité.
L'utilisateur d'une plateforme, c'est celui qui la consomme — nommez-le dans le Goal.
App opérateur. Sprint sur le suivi conso data.
« Faire fonctionner le widget de conso. »
« Faire fonctionner » n'est pas mesurable. Fonctionne pour qui ? Dans quel contexte ? À quel niveau de qualité ?
« « Permettre à un abonné mobile de suivre sa consommation data restante en temps réel depuis l'écran d'accueil. » »
Le Sprint Goal doit rester cohérent avec la Definition of Done : « fonctionne » n'est pas un état, c'est un vœu.
Un Sprint Goal exprime une capacité — la DoD garantit qu'elle fonctionne pour de vrai.
Téléservice de demande d'aide. Sprint sur le dépôt de pièces.
« Migrer le back-office sur le nouveau socle. »
Migration invisible pour l'usager. Aucun bénéfice livré. Ce n'est ni un outcome ni un engagement d'équipe.
« « Permettre à un usager de déposer l'ensemble de ses pièces justificatives en une seule fois, sans re-saisie. » »
Le Sprint Goal doit livrer de la valeur observable dès l'Increment. Une migration seule reste un moyen.
Une migration technique ne devient un Sprint Goal que si elle débloque un usage.
MVP SaaS RH. Sprint centré sur la validation d'un usage clé.
« Faire un maximum de features avant la démo investisseurs. »
Rythme cardiaque, pas Sprint Goal. Aucune direction, aucune priorité, aucune inspection possible.
« « Valider avec 5 utilisateurs pilotes que notre workflow de recrutement réduit leur temps de tri de moitié. » »
Le Sprint Goal peut être un objectif d'apprentissage — ce qui compte, c'est qu'il apporte de la valeur (ici, une décision produit).
Sur un MVP, le meilleur Sprint Goal est souvent un test à valider, pas une feature à livrer.
Plateforme data interne. Sprint sur les indicateurs commerciaux.
« Livrer les 6 dashboards demandés. »
Un dashboard livré n'est pas un dashboard utilisé. Le vrai enjeu est la décision qu'il permet.
« « Permettre à chaque directeur régional de piloter son CA hebdomadaire depuis un tableau de bord fiable. » »
Le Sprint Goal doit être compris par les parties prenantes — un directeur régional doit voir en quoi son quotidien change.
Livrer un dashboard ≠ créer une capacité de pilotage. Le Sprint Goal doit viser la seconde.
Assistant IA support client. Sprint sur la qualité des réponses.
« Améliorer le modèle. »
« Améliorer un modèle » n'a aucun sens sans utilisateur ni métrique. C'est un vœu, pas un engagement.
« « Faire passer à 80 % le taux de réponses jugées utiles par les clients sur les 20 intentions les plus fréquentes. » »
Sur un produit IA, le Sprint Goal doit rester ancré côté utilisateur — pas côté benchmark ou paramètre technique.
Un score modèle n'est utile que s'il se traduit par une capacité utilisateur observable.
App de paiement fractionné. Sprint sur le parcours de souscription.
« Câbler l'API du partenaire de scoring. »
Encore un objectif technique. On peut « câbler » l'API sans qu'un seul client puisse souscrire.
« « Permettre à un client éligible d'obtenir une réponse de paiement en 3 fois en moins de 15 secondes. » »
Le Sprint Goal est un engagement de l'équipe entière (Product Owner, Scrum Master, Developers) sur un résultat commun.
Un Sprint Goal fintech s'écrit toujours du point de vue du client, jamais du prestataire technique.
Enseigne retail. Sprint sur le click & collect.
« Livrer les fonctionnalités du sprint suivant en avance. »
Non-sens : livrer le Sprint suivant en avance ne guide personne. Aucun cap, aucune valeur, aucune focalisation.
« « Permettre à un client d'être notifié en temps réel dès que sa commande est prête à retirer en magasin. » »
Le Sprint Goal doit être défini pendant le Sprint Planning — il n'est ni une avance sur d'autres Sprints, ni un slogan marketing.
Un Sprint Goal cadre CE Sprint. Point.
3. Transformer un mauvais Sprint Goal — 10 exemples avant / après
La meilleure façon d'apprendre à formuler un bon Sprint Goal est de partir des formulations les plus courantes et de les retravailler. Voici 10 transformations directement inspirées de contextes réels rencontrés en Sprint Planning.
« Développer les US 12 à 25. »
« Permettre à un utilisateur de finaliser une réservation en moins de 2 minutes. »
« Corriger les 40 bugs du backlog. »
« Rendre le parcours de connexion utilisable sans blocage pour 100 % de nos utilisateurs. »
« Faire de la dette technique. »
« Réduire de moitié le temps de build pour permettre à l'équipe de livrer 3 fois par jour. »
« Créer une API pour les partenaires. »
« Permettre à un partenaire pilote de facturer une commande via notre API en une seule requête. »
« Finir le Sprint. »
« Rendre disponible le calcul de devis auto en ligne pour un premier segment de clients pilotes. »
« Améliorer les performances. »
« Faire passer le temps de chargement de la page produit sous les 1,5 s pour 90 % des visites mobile. »
« Mettre à jour le design system. »
« Homogénéiser les 5 écrans du parcours d'inscription pour supprimer les points de friction remontés en support. »
« Migrer la base de données. »
« Permettre à l'équipe support d'accéder à l'historique client complet depuis un seul outil. »
« Terminer l'epic « facturation ». »
« Permettre à un client PME d'émettre et d'envoyer une facture conforme depuis notre outil, en moins d'une minute. »
« Refondre le back-office. »
« Permettre à un gestionnaire de traiter un dossier client en 4 clics au lieu de 12. »
4. Les caractéristiques d'un excellent Sprint Goal
Un excellent Sprint Goal se reconnaît à 6 caractéristiques. Le tableau suivant les met en regard des formulations médiocres qu'on rencontre le plus souvent en Sprint Planning.
| Critère | Excellent Sprint Goal | Mauvais Sprint Goal |
|---|---|---|
| Clarté | Une phrase, comprise par tous en 30 s | Jargon technique ou slogan flou |
| Valeur | Bénéfice utilisateur ou métier explicite | Livraison technique sans effet visible |
| Focalisation | Un seul objectif prioritaire | Fourre-tout de sujets non liés |
| Faisabilité | Atteignable en un Sprint | Trop gros ou trop vague pour être fini |
| Motivation | Donne envie aux Developers de se lever | « On fait ce qui reste dans le backlog » |
| Résultat attendu | Inspectable en Sprint Review | Impossible à démontrer, uniquement statutaire |
5. Checklist — votre Sprint Goal est-il bon ?
Avant de figer votre Sprint Goal en fin de Sprint Planning, passez-le à cette checklist. Un vrai Sprint Goal coche les 10 cases.
6. Les 10 erreurs les plus fréquentes
Ces formulations reviennent constamment. Elles ressemblent à un Sprint Goal mais n'en sont pas. Les reconnaître, c'est la moitié du travail.
❌ « Développer les US 12 à 25. »
Une liste d'items n'est pas un objectif. Elle prive l'équipe de sa flexibilité et transforme le Sprint en tunnel.
❌ « Corriger les bugs. »
Objectif défensif, non priorisé, non mesurable. Impossible d'inspecter le résultat en Sprint Review.
❌ « Faire la dette technique. »
La dette n'est un Sprint Goal que si elle débloque une capacité — sans cela, elle reste un moyen.
❌ « Créer une API. »
Un endpoint n'apporte pas de valeur en soi. L'utilisateur n'est pas nommé, la valeur non plus.
❌ « Finir le Sprint. »
Non-objectif. Le Sprint finira de toute façon — la question est ce qu'il aura permis.
❌ « Wow-effect sur la nouvelle home. »
Non mesurable, non inspectable. Un slogan n'engage personne côté Scrum Team.
❌ « +12 % de MRR. »
Un KPI seul n'est pas un Sprint Goal — il manque l'utilisateur et la capacité livrée.
❌ « Refondre le module X. »
Une refonte peut ne rien changer côté utilisateur. Sans bénéfice explicite, ce n'est pas un Goal.
❌ « Livrer la facturation ET l'onboarding ET les notifications. »
Trois objectifs = zéro objectif. La Scrum Team ne peut pas arbitrer.
❌ « Prendre de l'avance sur le prochain Sprint. »
Le Sprint Goal cadre CE Sprint. Prendre de l'avance n'est ni un engagement ni un résultat.
7. Comparatifs — Sprint Goal vs les autres artefacts
Une grande partie des mauvais Sprint Goals viennent d'une confusion avec un autre artefact. Les 4 tableaux suivants tracent la frontière.
Sprint Goal vs Product Goal
| Dimension | Sprint Goal | Product Goal |
|---|---|---|
| Horizon | Un Sprint | 3 à 12 mois |
| Portée | Increment du Sprint | Produit entier |
| Engagement | Sprint Backlog | Product Backlog |
| Défini par | Toute la Scrum Team en Sprint Planning | Product Owner |
Pour approfondir : Product Goal et Product Backlog.
Sprint Goal vs Sprint Backlog
| Dimension | Sprint Goal | Sprint Backlog |
|---|---|---|
| Nature | Objectif — le « pourquoi » | Plan — le « quoi » et le « comment » |
| Stabilité | Reste stable pendant le Sprint | Émergent, ajustable chaque jour |
| Engagement | Engagement du Sprint Backlog | Contient PBI sélectionnés + plan de livraison |
| Propriétaire | Scrum Team | Developers |
Sprint Goal vs Roadmap
| Dimension | Sprint Goal | Roadmap |
|---|---|---|
| Nature | Objectif de valeur d'un Sprint | Séquencement de livraisons dans le temps |
| Horizon | Un Sprint | Plusieurs mois à plusieurs trimestres |
| Scrum Guide | Officiel (2020) | Non défini dans Scrum |
| Utilité | Aligner la Scrum Team sur un résultat | Communiquer aux parties prenantes |
Sprint Goal vs Epic
| Dimension | Sprint Goal | Epic |
|---|---|---|
| Nature | Objectif d'un Sprint | Regroupement de PBI |
| Portée | Un seul par Sprint | Étalé sur plusieurs Sprints |
| Focalisation | Résultat utilisateur atteignable maintenant | Structuration du backlog |
| Rôle | Donner un cap au Sprint | Organiser le travail à moyen terme |
8. Comment construire un Sprint Goal — méthode en 7 étapes
Un bon Sprint Goal ne s'invente pas en 2 minutes en fin de Sprint Planning. Il se construit à partir du Product Goal, en dialogue entre Product Owner et Developers.
- Product Goal — Repartez du Product Goal en cours. Sans lui, un Sprint Goal n'a pas de sens produit.
- Sprint Planning — Ouvrez le Sprint Planning par la question « Pourquoi ce Sprint est-il précieux ? ».
- Valeur attendue — Nommez l'utilisateur et le bénéfice ciblés dans le Sprint.
- Sprint Goal — Formulez une phrase unique, orientée résultat, atteignable en un Sprint.
- Sélection du Sprint Backlog — Les Developers sélectionnent les PBI qui servent réellement le Sprint Goal.
- Inspection — À chaque Daily Scrum, inspectez la progression vers le Sprint Goal, pas la liste de tickets.
- Adaptation — Négociez la portée du Sprint Backlog avec le Product Owner si nécessaire — le Sprint Goal, lui, reste stable.
Cette méthode s'appuie sur les trois piliers du Scrum : transparence, inspection, adaptation. Elle relie directement le Sprint Goal aux engagements des autres artefacts — le Product Goal pour le Product Backlog, la Definition of Done pour l'Increment.
9. Comment le Sprint Goal cadre le Sprint Backlog
Un Sprint Goal fort transforme le Sprint Backlog. Chaque PBI doit pouvoir répondre à la question : « en quoi contribue-t-il au Sprint Goal ? ». Si la réponse est floue, le PBI sort du Sprint — ou redevient un candidat pour un Sprint futur. C'est ce qui distingue un Sprint piloté par la valeur d'un simple tunnel de tickets.
Le Sprint Goal permet aussi à la Scrum Team d'arbitrer en cours de Sprint : quel scope négocier, quelle dette technique accepter, quel raccourci refuser. Un Increment n'a de valeur que s'il rapproche l'équipe du Sprint Goal.