Que fait Propriétaire de Produit Agile ?
Boîte à outils de gestion du backlog et d'exécution des sprints pour les propriétaires de produit, incluant la génération de user stories, les patrons de critères d'acceptation, la planification des sprints et le suivi de la vélocité.
Table des matières
- Workflow de génération de User Stories
- Patrons de critères d'acceptation
- Workflow de décomposition d'Epic
- Workflow de planification de Sprint
- Priorisation du Backlog
- Documentation de référence
- Outils
Workflow de génération de User Stories
Créez des user stories conformes aux critères INVEST à partir d'exigences :
- Identifiez la personne (qui bénéficie de cette fonctionnalité)
- Définissez l'action ou la capacité nécessaire
- Exprimez le bénéfice ou la valeur apportée
- Rédigez les critères d'acceptation au format Given-When-Then
- Estimez les story points avec l'échelle de Fibonacci
- Validez par rapport aux critères INVEST
- Ajoutez au backlog avec priorité
- Validation : La story satisfait tous les critères INVEST ; les critères d'acceptation sont testables
Modèle de User Story
En tant que [persona],
Je veux [action/capacité],
Afin de [bénéfice/valeur].
Exemple :
En tant que responsable marketing,
Je veux exporter les rapports de campagne en PDF,
Afin de partager les résultats avec les parties prenantes qui n'ont pas accès au système.
Types de Stories
| Type | Modèle | Exemple |
|---|---|---|
| Fonctionnalité | En tant que [persona], je veux [action] afin de [bénéfice] | En tant qu'utilisateur, je veux filtrer les résultats de recherche afin de trouver des articles plus rapidement |
| Amélioration | En tant que [persona], j'ai besoin de [capacité] pour [objectif] | En tant qu'utilisateur, j'ai besoin de pages qui se chargent plus vite pour accomplir des tâches sans frustration |
| Correction de bug | En tant que [persona], je m'attends à [comportement] quand [condition] | En tant qu'utilisateur, je m'attends à ce que mon panier persiste quand je rafraîchis la page |
| Enabler | En tant que développeur, j'ai besoin de [tâche technique] pour permettre [capacité] | En tant que développeur, j'ai besoin d'implémenter la mise en cache pour permettre la recherche instantanée |
Référence des Personas
| Persona | Besoins typiques | Contexte |
|---|---|---|
| Utilisateur final | Efficacité, simplicité, fiabilité | Utilisation quotidienne des fonctionnalités |
| Administrateur | Contrôle, visibilité, sécurité | Gestion du système |
| Utilisateur avancé | Automatisation, personnalisation, raccourcis | Workflows experts |
| Nouvel utilisateur | Guidage, apprentissage, sécurité | Intégration |
Patrons de critères d'acceptation
Rédigez des critères d'acceptation testables au format Given-When-Then.
Modèle Given-When-Then
Étant donné [précondition/contexte],
Quand [action/déclencheur],
Alors [résultat attendu].
Exemples :
Étant donné que l'utilisateur est connecté avec des identifiants valides,
Quand il clique sur le bouton "Exporter",
Alors un téléchargement PDF commence dans les 2 secondes.
Étant donné que l'utilisateur a saisi un format d'email invalide,
Quand il soumet le formulaire d'inscription,
Alors un message d'erreur en ligne affiche "Veuillez saisir une adresse email valide."
Étant donné que le panier d'achat contient des articles,
Quand l'utilisateur rafraîchit le navigateur,
Alors le contenu du panier reste inchangé.
Liste de vérification des critères d'acceptation
Chaque story doit inclure des critères pour :
| Catégorie | Exemple |
|---|---|
| Chemin heureux | Étant donné une entrée valide, Quand soumis, Alors message de succès affiché |
| Validation | Doit rejeter la saisie quand un champ obligatoire est vide |
| Gestion d'erreur | Doit afficher un message convivial quand l'API échoue |
| Performance | Doit effectuer l'opération dans les 2 secondes |
| Accessibilité | Doit être navigable uniquement au clavier |
Critères minimaux par taille de story
| Story Points | Nombre minimum de critères |
|---|---|
| 1-2 | 3-4 critères |
| 3-5 | 4-6 critères |
| 8 | 5-8 critères |
| 13+ | Divisez la story |
Voir references/user-story-templates.md pour la bibliothèque complète de modèles.
Workflow de décomposition d'Epic
Décomposez les epics en stories de taille sprint livrables :
- Définissez le périmètre de l'epic et ses critères de succès
- Identifiez tous les personas affectés par l'epic
- Listez toutes les capacités nécessaires pour chaque persona
- Regroupez les capacités en stories logiques
- Validez que chaque story fait ≤8 points
- Identifiez les dépendances entre les stories
- Ordonnez les stories pour une livraison incrémentale
- Validation : Chaque story apporte une valeur autonome ; le total des stories couvre le périmètre de l'epic
Techniques de découpage
| Technique | Quand l'utiliser | Exemple |
|---|---|---|
| Par étape de workflow | Processus linéaire | "Checkout" → "Ajouter au panier" + "Saisir le paiement" + "Confirmer la commande" |
| Par persona | Plusieurs types d'utilisateurs | "Tableau de bord" → "Tableau de bord admin" + "Tableau de bord utilisateur" |
| Par type de données | Entrées multiples | "Import" → "Importer CSV" + "Importer Excel" |
| Par opération | Fonctionnalité CRUD | "Gérer les utilisateurs" → "Créer" + "Modifier" + "Supprimer" |
| Chemin heureux en premier | Réduction des risques | "Fonctionnalité" → "Flux de base" + "Gestion des erreurs" + "Cas limites" |
Exemple d'Epic
Epic : Tableau de bord utilisateur
Décomposition :
Epic: Tableau de bord utilisateur (34 points au total)
├── US-001: Voir les métriques clés (5 pts) - Utilisateur final
├── US-002: Personnaliser la mise en page (5 pts) - Utilisateur avancé
├── US-003: Exporter les données en CSV (3 pts) - Utilisateur final
├── US-004: Partager avec l'équipe (5 pts) - Utilisateur final
├── US-005: Configurer des alertes (5 pts) - Utilisateur avancé
├── US-006: Filtrer par plage de dates (3 pts) - Utilisateur final
├── US-007: Vue d'ensemble admin (5 pts) - Admin
└── US-008: Activer la mise en cache (3 pts) - Enabler
Workflow de planification de Sprint
Planifiez la capacité du sprint et sélectionnez les stories :
- Calculez la capacité de l'équipe (vélocité × disponibilité)
- Révisez l'objectif du sprint avec les parties prenantes
- Sélectionnez les stories du backlog priorisé
- Remplissez à 80-85 % de la capacité (engagé)
- Ajoutez des objectifs d'extension (10-15 % supplémentaires)
- Identifiez les dépendances et les risques
- Décomposez les stories complexes en tâches
- Validation : Points engagés ≤85 % de la capacité ; toutes les stories ont des critères d'acceptation
Calcul de capacité
Capacité du sprint = Vélocité moyenne × Facteur de disponibilité
Exemple :
Vélocité moyenne : 30 points
Disponibilité de l'équipe : 90 % (un membre partiellement absent)
Capacité ajustée : 27 points
Engagé : 23 points (85 % de 27)
Extension : 4 points (15 % de 27)
Facteurs de disponibilité
| Scénario | Facteur |
|---|---|
| Sprint complet, pas de congés | 1.0 |
| Un membre de l'équipe absent à 50 % | 0.9 |
| Jour férié pendant le sprint | 0.8 |
| Plusieurs membres absents | 0.7 |
Modèle de chargement du sprint
Capacité du sprint : 27 points
Objectif du sprint : [Objectif clair et mesurable]
ENGAGÉ (23 points) :
[H] US-001: Tableau de bord utilisateur (5 pts)
[H] US-002: Fonctionnalité d'export (3 pts)
[H] US-003: Filtre de recherche (5 pts)
[M] US-004: Page des paramètres (5 pts)
[M] US-005: Info-bulles d'aide (3 pts)
[L] US-006: Options de thème (2 pts)
EXTENSION (4 points) :
[L] US-007: Options de tri (2 pts)
[L] US-008: Vue d'impression (2 pts)
Voir references/sprint-planning-guide.md pour les procédures de planification complètes.
Priorisation du Backlog
Priorisez le backlog en utilisant une évaluation de la valeur et de l'effort.
Niveaux de priorité
| Priorité | Définition | Cible du sprint |
|---|---|---|
| Critique | Bloque les utilisateurs, sécurité, perte de données | Immédiat |
| Élevée | Fonctionnalité de base, besoins clés des utilisateurs | Ce sprint |
| Moyenne | Améliorations, rehaussements | 2-3 prochains sprints |
| Faible | Agréable à avoir, améliorations mineures | Backlog |
Facteurs de priorisation
| Facteur | Poids | Questions |
|---|---|---|
| Valeur métier | 40 % | Impact sur le revenu ? Demande des utilisateurs ? Alignement stratégique ? |
| Impact utilisateur | 30 % | Combien d'utilisateurs ? Fréquence d'utilisation ? |
| Risque/Dépendances | 15 % | Risque technique ? Dépendances externes ? |
| Effort | 15 % | Taille ? Complexité ? Incertitude ? |
Validation des critères INVEST
Avant d'ajouter au sprint, validez chaque story :
| Critère | Question | Réussite si... |
|---|---|---|
| Indépendante | Peut-elle être développée sans autres stories non engagées ? | Aucune dépendance bloquante |
| Négociable | La mise en œuvre est-elle flexible ? | Plusieurs approches possibles |
| Valorisante | Apporte-t-elle de la valeur utilisateur ou métier ? | Bénéfice clair dans "afin de" |
| Estimable | L'équipe peut-elle l'estimer ? | Assez bien comprise pour être dimensionnée |
| Small | Peut-elle être terminée en un sprint ? | ≤8 story points |
| Testable | Pouvons-nous vérifier qu'elle est terminée ? | Critères d'acceptation clairs |
Documentation de référence
Modèles de User Stories
references/user-story-templates.md contient :
- Formats standard de stories par type (fonctionnalité, amélioration, correction de bug, enabler)
- Patrons de critères d'acceptation (Given-When-Then, Should/Must/Can)
- Liste de vérification de validation INVEST
- Guide d'estimation des story points (échelle de Fibonacci)
- Antipatterns courants et correctifs
- Techniques de découpage de stories
Guide de planification de Sprint
references/sprint-planning-guide.md contient :
- Ordre du jour de la réunion de planification de sprint
- Formules de calcul de capacité
- Cadre de priorisation du backlog (WSJF)
- Guides des cérémonies de sprint (mêlée, revue, rétrospective)
- Patrons de suivi de vélocité et de burndown
- Liste de vérification de la Définition de Fini
- Métriques et cibles du sprint
Outils
Générateur de User Stories
# Générer des stories à partir d'un exemple d'epic
python scripts/user_story_generator.py
# Planifier un sprint avec capacité
python scripts/user_story_generator.py sprint 30
Génère :
- User stories conformes INVEST
- Critères d'acceptation Given-When-Then
- Estimations de story points (échelle de Fibonacci)
- Attributions de priorité
- Chargement du sprint avec éléments engagés et d'extension
Exemple de sortie
USER STORY: USR-001
========================================
Titre: Voir les métriques clés
Type: story
Priorité: HAUTE
Points: 5
Story:
En tant qu'utilisateur final, je veux voir les métriques clés et les KPI
afin de gagner du temps et de travailler plus efficacement
Critères d'acceptation:
1. Étant donné que l'utilisateur a accès, Quand il voit les métriques clés, Alors le résultat est affiché
2. Doit valider l'entrée avant traitement
3. Doit afficher un message d'erreur clair quand l'action échoue
4. Doit se terminer dans les 2 secondes
5. Doit être accessible via la navigation au clavier
Liste de vérification INVEST:
✓ Indépendante
✓ Négociable
✓ Valorisante
✓ Estimable
✓ Petite
✓ Testable
Métriques de Sprint
Suivez la santé du sprint et la performance de l'équipe.
Métriques clés
| Métrique | Formule | Cible |
|---|---|---|
| Vélocité | Points terminés / sprint | Stable ±10 % |
| Fiabilité d'engagement | Terminés / Engagés | >85 % |
| Changement de périmètre | Points ajoutés ou supprimés en cours de sprint | <10 % |
| Report | Points non terminés | <15 % |
Suivi de vélocité
Sprint 1 : 25 points
Sprint 2 : 28 points
Sprint 3 : 30 points
Sprint 4 : 32 points
Sprint 5 : 29 points
------------------------
Vélocité moyenne : 28,8 points
Tendance : Stable
Planification : S'engager sur 24-26 points
Définition de Fini
Une story est terminée quand :
- Code complet et revu par les pairs
- Tests unitaires écrits et passants
- Critères d'acceptation vérifiés
- Documentation mise à jour
- Déployé dans l'environnement de staging
- Accepté par le propriétaire de produit
- Aucun bug critique restant
Compétences connexes
- Scrum Master (
project-management/scrum-master/) — Les données de vélocité et les cérémonies de sprint complètent la gestion du backlog - Boîte à outils du Chef de Produit (
product-team/product-manager-toolkit/) — La priorisation RICE alimente l'ordonnancement du backlog