Bibliothèque · Définition · Intermédiaire
Product Goal : l'objectif qui ordonne le backlog
L'état futur visé pour le produit, engagement du product backlog. Un seul à la fois, à atteindre ou abandonner avant le suivant, avec critères de succès, échéance et métriques.
Pour qui, pour quand
En résumé
Le product goal décrit l'état futur visé pour le produit, et le backlog se construit pour l'atteindre. On n'en poursuit qu'un à la fois, et on l'atteint (ou on l'abandonne) avant de passer au suivant. Une roadmap peut en enchaîner plusieurs dans l'année.
Il change la priorisation : un item compte par sa contribution au goal, pas par sa valeur isolée. Le backlog doit porter des résultats attendus plutôt que des solutions figées. Pour qu'il soit mesurable, il faut au minimum une description, des critères de succès, une échéance, des métriques et une stratégie de mise en œuvre.
Méthode étape par étape
dans l'ordre, sans en sauter
- 01Écrire le product goal : l'état futur, pas une liste de fonctionnalités.
- 02Lui donner des critères de succès, une échéance et des métriques.
- 03Réordonner le backlog selon la contribution de chaque item au goal.
- 04Relier chaque sprint goal au product goal.
- 05À échéance : atteint, abandonné ou prolongé, en le décidant explicitement.
Questions à me poser
avant de te lancer
- →Qu'est-ce qui sera vrai pour l'utilisateur quand ce goal sera atteint ?
- →Poursuivons-nous plusieurs goals à la fois sans le dire ?
Ce qui coûte cher
les pièges déjà vus sur ce sujet
Dans ma bible
SCRUM · p. 166-167
Chargement du passage…
Sources citées : Scrum Life
Mes notes
ce que tu retiens, ton contexte
Situations couvertes
- · Mes sprint goals n'ont aucun lien avec la stratégie
- · Je dois prioriser un backlog
- · Je dois préparer une roadmap
Provenance
Ma bible PM · SCRUM, p. 166-167 · d'après Scrum Life
ajoutée le 2026-09-18
Mots-clés
À lire juste après
ce que cette fiche appelle
Ce qui renvoie ici
des fiches qui citent celle-ci - c'est là que tes REX réapparaissent