Cette page rassemble les meilleurs Sprint Goal examples francophones : quatre cas réels (banque, e-commerce, mobile, RH), une analyse détaillée de leur efficacité, une galerie de mauvais Sprint Goals avec leurs versions corrigées, et tous les pièges PSM I associés. Elle complète le pilier Sprint Goal, le guide Sprint Scrum et la page Sprint Planning pour passer de la théorie à la pratique.
Qu'est-ce qu'un bon Sprint Goal ?
Un bon Sprint Goal est l'unique objectif d'un Sprint, défini lors du Sprint Planning, qui donne un sens commun au travail de l'équipe et permet aux stakeholders de comprendre la valeur attendue. Selon le Scrum Guide 2020, il est l'engagement du Sprint Backlog — pas la somme des tickets, mais leur raison d'être.
Trois caractéristiques distinguent un bon scrum Sprint Goal example d'un objectif vague :
- Orientation résultat : il décrit un changement pour l'utilisateur ou le métier, pas une liste de tâches techniques.
- Unicité : un seul objectif par Sprint, qui sert de boussole en cas de conflit de priorités.
- Alignement : il fait progresser le Product Goal en cours.
Pourquoi un Sprint Goal est indispensable
Un Sprint sans Sprint Goal n'est pas un Sprint Scrum, c'est une boîte de tickets. Le Sprint Goal joue quatre rôles essentiels :
- Boussole quotidienne : il oriente les arbitrages du Daily Scrum et les renégociations du Sprint Backlog.
- Mécanisme d'engagement : il transforme une liste imposée en projet collectif porté par l'équipe.
- Critère de succès : il rend la Sprint Review claire — atteint, partiel ou raté — et ouvre la discussion produit.
- Garde-fou stratégique : il rappelle pourquoi on construit, ce qui empêche la dérive « fonctionnalité après fonctionnalité ».
La chaîne d'objectifs Scrum
Exemple n°1 — Application bancaire
Sprint Goal — Application bancaire mobile
- Contexte
- Banque en ligne, équipe de 6 Developers, Sprint de 2 semaines. La fonctionnalité « virement instantané » est demandée par 60 % des utilisateurs interrogés.
- Product Goal
- Devenir la banque mobile préférée des 25-35 ans en France d'ici 12 mois.
- Sprint Goal
- « Permettre à un utilisateur authentifié d'effectuer un virement instantané SEPA de son compte courant vers un bénéficiaire enregistré, en moins de 30 secondes. »
- Sprint Backlog
- UI de saisie du virement · validation côté serveur · intégration API SEPA Instant · gestion des erreurs réseau · télémétrie temps de traitement · tests E2E.
- Increment obtenu
- Virement instantané fonctionnel en production pour 100 % des utilisateurs Premium. Temps moyen mesuré : 22 secondes. Taux d'erreur : 0,3 %.
- Enseignements
- Le Sprint Goal centré sur l'utilisateur a permis de couper en cours de Sprint une fonctionnalité « bénéficiaires favoris » initialement prévue : elle ne servait pas le Sprint Goal et a été reportée. La discussion en Daily Scrum a été beaucoup plus simple : « est-ce que cela rapproche du virement en 30 s ? ».
Exemple n°2 — Plateforme e-commerce
Sprint Goal — E-commerce mode
- Contexte
- Site e-commerce de mode, 8 Developers, Sprint de 2 semaines. Le taux d'abandon panier dépasse 72 %, principalement sur l'étape « adresse de livraison ».
- Product Goal
- Augmenter le taux de conversion mobile de 1,8 % à 3 % sur 2 trimestres.
- Sprint Goal
- « Réduire d'au moins 15 % le taux d'abandon panier sur l'étape adresse, sans dégrader le temps de chargement mobile. »
- Sprint Backlog
- Refonte du formulaire adresse (1 écran au lieu de 3) · auto-complétion adresse (API tierce) · sauvegarde brouillon panier · A/B test 50/50 · dashboard de mesure.
- Increment obtenu
- Variante B livrée à 50 % du trafic mobile. Abandon panier mesuré sur 7 jours : -18 % vs variante A. Temps de chargement stable (1,9 s vs 1,8 s avant).
- Enseignements
- Le Sprint Goal mesurable a aligné Developers, PO et stakeholders. La discussion en Sprint Review a porté sur le résultat (-18 %), pas sur l'effort. Une idée non prévue (sauvegarde brouillon panier) a été ajoutée en cours de Sprint car elle servait directement le Sprint Goal.
Exemple n°3 — Application mobile (santé)
Sprint Goal — Application mobile suivi sportif
- Contexte
- Application iOS/Android de suivi sportif, 5 Developers, Sprint de 1 semaine. Les utilisateurs free perdent leur historique au-delà de 7 jours et désinstallent.
- Product Goal
- Atteindre 100 000 utilisateurs actifs mensuels et 5 % de conversion en abonnement Premium.
- Sprint Goal
- « Offrir aux utilisateurs free 30 jours d'historique de leurs séances, accessible en mode hors-ligne, pour réduire la désinstallation post-J7. »
- Sprint Backlog
- Stockage local SQLite · synchronisation cloud différée · migration des comptes existants · UI « historique » améliorée · télémétrie désinstallation.
- Increment obtenu
- Fonctionnalité livrée sur les deux plateformes. Mesure à J+14 : -22 % de désinstallation entre J7 et J14 sur la cohorte exposée.
- Enseignements
- Le lien Sprint Goal → Product Goal était limpide : moins de désinstallation = plus d'utilisateurs actifs = plus de conversions Premium. Cette clarté a évité une dérive vers une refonte UI esthétique de l'historique, hors scope du Sprint Goal.
Exemple n°4 — Refonte d'un portail RH
Sprint Goal — Portail RH interne
- Contexte
- Refonte d'un portail RH legacy utilisé par 4 000 salariés. 7 Developers, Sprint de 3 semaines. La pose de congés génère 60 % des tickets support RH.
- Product Goal
- Supprimer 80 % des tickets support liés aux self-services RH d'ici la fin de l'année.
- Sprint Goal
- « Permettre à un salarié de poser une demande de congé bout en bout depuis le nouveau portail, avec validation manager, sans recourir au support. »
- Sprint Backlog
- Formulaire de demande · règles métier (solde, jours fériés) · workflow validation manager · notifications mail/Teams · journalisation pour audit RH · migration des demandes en cours.
- Increment obtenu
- Parcours complet déployé sur un pilote de 200 salariés. 95 % des demandes de congés sur la cohorte ont été traitées sans ticket support. Feedback : interface jugée « beaucoup plus simple » par 87 % des testeurs.
- Enseignements
- Le Sprint Goal a forcé l'équipe à livrer un parcours bout en bout, pas une « brique » technique. La tentation initiale de séparer « formulaire » / « workflow » / « notifications » en trois Sprints aurait empêché toute mesure réelle de réduction du support.
Pourquoi ces Sprint Goals fonctionnent
Les quatre Sprint Goal samples présentés ci-dessus partagent six caractéristiques que l'on retrouve dans tout bon Sprint Goal :
| Caractéristique | Pourquoi c'est efficace |
|---|---|
| Centré utilisateur ou métier | Permet d'arbitrer en faveur de l'usage final, pas de la facilité technique. |
| Résultat mesurable | Rend la Sprint Review factuelle : atteint, partiel, raté. |
| Bout en bout | Force la livraison d'une tranche de valeur complète, pas d'une brique isolée. |
| Aligné avec le Product Goal | Connecte chaque Sprint à la stratégie produit, évite le bricolage. |
| Court et compréhensible | Tient en une à deux phrases, lisible par n'importe quel stakeholder. |
| Solution non verrouillée | Laisse les Developers libres de choisir le « comment ». |
Exemple, analyse, résultat
| Exemple | Analyse | Résultat |
|---|---|---|
| Banque — virement 30 s | Cible un usage clair, contrainte mesurable | Fonctionnalité en production, 22 s mesurés |
| E-commerce — −15 % abandon | Métrique mesurable, lien direct au Product Goal conversion | −18 % d'abandon, conversion mobile en hausse |
| Mobile santé — 30 j historique | Résout une cause de désinstallation identifiée | −22 % de désinstallation post-J7 |
| RH — congés bout en bout | Parcours complet plutôt que briques techniques | 95 % de demandes sans support |
Mauvais Sprint Goals et corrections
Les mauvais Sprint Goals partagent trois symptômes : ils décrivent l'effort plutôt que le résultat, ils mélangent plusieurs objectifs ou ils ne disent rien que le board ne dise déjà. Voici les contre-exemples les plus fréquents et leur correction.
| Mauvais Sprint Goal | Pourquoi c'est mauvais | Version corrigée |
|---|---|---|
| « Terminer tous les tickets du Sprint Backlog » | Pas un objectif, juste un engagement de volume. Ne guide aucune décision. | « Réduire d'au moins 15 % le taux d'abandon panier sur l'étape adresse. » |
| « Travailler sur le module paiement » | Vague, pas de résultat utilisateur, pas de critère de succès. | « Permettre à un utilisateur de payer en moins de 3 clics avec Apple Pay. » |
| « Sprint Goal n°47 » | Aucune valeur, aucune lisibilité pour les stakeholders ni l'équipe. | « Stabiliser la latence des recherches sous 300 ms au 95e percentile. » |
| « Faire ce que demande le COMEX » | Aucun engagement de l'équipe, pas d'orientation produit, pas de critère. | « Lancer une bêta privée du nouveau dashboard auprès de 50 clients prioritaires. » |
| « Améliorer la qualité du code » | Activité interne, pas de résultat observable côté utilisateur. | « Réduire à zéro les incidents P1 liés au module paiement pendant le Sprint suivant. » |
| « Livrer les features A, B, C et D » | Quatre objectifs concurrents, pas un. | « Permettre à un nouveau client de s'inscrire et passer sa première commande. » |
Erreurs fréquentes
| Erreur | Conséquence | Bonne pratique |
|---|---|---|
| Définir le Sprint Goal après le Sprint Backlog | Le SG devient la justification a posteriori d'une sélection de tickets. | Why → What → How : commencer par le Sprint Goal. |
| Avoir plusieurs Sprint Goals | Concentration diluée, pas d'arbitrage possible. | Un seul Sprint Goal, point. |
| Changer le Sprint Goal en cours de Sprint | Casse l'empirisme et la confiance des stakeholders. | Si la situation l'exige, le PO annule le Sprint. |
| Sprint Goal imposé par le management | Désengagement de l'équipe, pas d'appropriation. | Le Scrum Team co-définit le Sprint Goal en Planning. |
| Sprint Goal trop technique | Stakeholders ne comprennent pas la valeur livrée. | Formulation orientée utilisateur ou métier. |
| Sprint Goal jamais évoqué en Daily | Le SG redevient décoratif. | Chaque Daily : « ce que je fais aujourd'hui rapproche-t-il du Sprint Goal ? ». |
Bonnes pratiques inspirées du Scrum Guide
- Le Sprint Goal est l'engagement du Sprint Backlog. Il est défini en Sprint Planning, avant que la sélection des Product Backlog Items soit figée.
- Le Sprint Goal ne change pas pendant le Sprint. Seul le contenu du Sprint Backlog peut être renégocié entre Developers et Product Owner.
- Le Sprint Goal est visible en permanence en haut du Sprint Backlog — dans Jira, Trello, Linear ou n'importe quel outil.
- La Sprint Review commence par un rappel du Sprint Goal et son atteinte. C'est la première donnée d'inspection.
- La Sprint Retrospective qui suit est l'occasion d'inspecter la qualité du Sprint Goal lui-même : était-il clair ? réaliste ? motivant ?
Conseils pour réussir le PSM I sur le Sprint Goal
FAQ — Sprint Goal Example
Les 12 questions ci-dessous synthétisent les interrogations les plus fréquentes autour des Sprint Goal examples. Elles sont également exposées en JSON-LD pour aider Google et les moteurs IA à comprendre le contenu de cette page.