i

Description

Un tableau blanc couvert de notes adhésives réparties en colonnes

Source

無聊龍 · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Scrum en pratique

Vous saurez tenir un Product Backlog vivant, écrire des user stories testables (INVEST, critères d'acceptation), les découper verticalement.

En bref

• Vous saurez tenir un Product Backlog vivant, écrire des user stories testables (INVEST, critères d'acceptation), les découper verticalement.
• Vous saurez estimer de trois façons (points, taille relative, flux / #NoEstimates), utiliser la vélocité sans la détourner et lire des métriques de flux.
• Vous saurez distinguer Definition of Ready et Definition of Done, animer une planification et une rétrospective qui change quelque chose.
• Vous saurez reconnaître les anti-patterns (ScrumBut, Scrumerfall…), mettre en place une équipe, travailler à distance, passer à l'échelle et contractualiser.
• Vous repartirez avec une liste de 30 pièges et une grille de notes /5.
• Le cadre lui-même est dans Scrum, le cadre ; l'application à la BI dans Scrum et data.

Sur cette page

1. 🟢 Novice — Le Product Backlog au quotidien
   1. Forme d'un bon backlog : « DEEP »
   2. Types d'items et mix
   3. Le Product Owner « écrit » ou « possède » ?
2. 🟢 Novice — User stories et INVEST
   1. Le critère INVEST (Bill Wake)
   2. Le cas des stories techniques et data
3. 🟢 Novice — Critères d'acceptation
4. 🟢 Novice — Découper une story
   1. Le principe : la tranche verticale
   2. Neuf schémas de découpage (inspirés de Richard Lawrence)
5. 🟡 Pratique — Raffinement (refinement)
   1. Une séance efficace
   2. Combien de backlog « prêt » ?
6. 🟡 Pratique — Estimation : points, flux, #NoEstimates
   1. 1. Points d'histoire (story points)
   2. 2. Prévision par le flux (sans points)
   3. 3. #NoEstimates
   4. Estimer le travail data : les spécificités
7. 🟡 Pratique — Vélocité et ses abus
8. 🟡 Pratique — Métriques utiles
9. 🟡 Pratique — Definition of Ready contre Definition of Done
10. 🟡 Pratique — Planifier un Sprint
    1. Règles de bon sens
11. 🟡 Pratique — La rétrospective qui change quelque chose
    1. Structure type (60 à 90 minutes pour un Sprint de 2 semaines)
    2. Formats
    3. Les cinq causes d'une rétro inutile
12. 🟡 Pratique — Mettre en place une équipe Scrum
    1. Préalables
    2. Séquence de démarrage (4 à 6 semaines)
    3. Rôles : cumuls et tailles
    4. Former sans dogme
13. 🔴 Expert — Anti-patterns et ScrumBut
    1. Quand abandonner Scrum
14. 🔴 Expert — Scrum à distance
15. 🔴 Expert — Passer à l'échelle
    1. Réduire les dépendances plutôt que les coordonner
16. 🔴 Expert — Scrum et contrats
17. 🔴 Expert — Trente pièges
18. Métriques : notes /5
19. Contribution de l'IA
20. Voir aussi

Niveau : 🟢→🔴

🟢 Novice — Le Product Backlog au quotidien#

Le Product Backlog est la liste ordonnée de tout ce qui pourrait améliorer le produit (cadre : Scrum, le cadre). En pratique, on y trouve des fonctionnalités, des corrections, des améliorations techniques, des expériences/spikes et des travaux d'exploitation. Il n'est ni un entrepôt d'idées illimité, ni un cahier des charges.

Forme d'un bon backlog : « DEEP »#

Roman Pichler et Mike Cohn ont popularisé le moyen mnémotechnique DEEP :

Types d'items et mix#

Le Product Owner « écrit » ou « possède » ?#

Le PO est redevable du backlog, il n'a pas à tout écrire. Les Developers, le métier et le SM peuvent proposer ; le PO trie, ordonne et dit non. Un backlog géré comme une boîte de réception de demandes est un symptôme : ordonner suppose de renoncer.

🟢 Novice — User stories et INVEST#

Une user story décrit un besoin du point de vue de l'utilisateur, brièvement, comme invitation à la conversation. Ron Jeffries a résumé les « 3 C » : Card (une carte, pas un contrat), Conversation (le vrai contenu est dans la discussion), Confirmation (critères d'acceptation). Elle n'est pas dans le Scrum Guide (voir ce que le Guide ne dit pas).

Gabarit usuel :

Le critère INVEST (Bill Wake)#

Le cas des stories techniques et data#

« Valuable » pose problème pour le travail d'infrastructure : charger une table de faits, optimiser un index. Deux écoles :

1. Éviter les stories purement techniques : les porter par une story de valeur (« voir le CA par client » englobe de charger la table de faits). La valeur est tirée vers le bas par l'usage.
2. Autoriser des items techniques explicitement justifiés (dette, risque, prérequis), mais les garder rares, petits et reliés à un objectif.

Cette tension est centrale en BI ; elle est traitée dans Scrum et data. Autres formes que « En tant que » : Job Stories (« quand [situation], je veux [motivation], pour [résultat attendu] »), cas d'usage, hypothèses (« nous croyons que… »). Peu importe la forme si le pourquoi et la confirmation y sont.

🟢 Novice — Critères d'acceptation#

Les critères d'acceptation bornent une story : ce qu'il faut démontrer pour la dire terminée au sens de cette story. Ils sont distincts de la Definition of Done qui s'applique à toutes les stories (voir DoR contre DoD).

Deux formes courantes :

Fonctionnalité: CA mensuel par client
  Scénario: Client avec deux factures dans le mois
    Étant donné un client "C-100" avec les factures 1 200,00 et 300,00 en mars 2026
    Quand j'affiche le CA de mars 2026 pour "C-100"
    Alors la valeur affichée est 1 500,00
  Scénario: Client sans vente
    Étant donné un client "C-200" sans facture en mars 2026
    Quand j'affiche le CA de mars 2026
    Alors "C-200" apparaît avec 0,00

Les scénarios traduits en tests (SQL, DAX, requête de comparaison) deviennent des tests de non-régression exécutables à chaque livraison — la base d'un test de chiffres. Voir Tests et fiabilité des chiffres.

🟢 Novice — Découper une story#

Une story trop grosse ne tient pas dans un Sprint, ne peut être testée qu'à la fin, et cache de l'incertitude. Découper est le geste le plus rentable du raffinement.

Le principe : la tranche verticale#

Une tranche verticale traverse toutes les couches (source → transformation → modèle → restitution) pour livrer un petit bout de valeur utilisable. L'opposé est la tranche horizontale : « toute la couche d'extraction d'abord, puis tout le modèle, puis tous les rapports », qui ne livre rien d'utilisable avant la fin.

Neuf schémas de découpage (inspirés de Richard Lawrence)#

🟡 Pratique — Raffinement (refinement)#

Le raffinement est continu et responsabilité de la Scrum Team (voir artefacts). En pratique, la plupart des équipes planifient une ou deux séances par Sprint (30 à 90 minutes) en complément de la clarification au fil de l'eau. Le Guide n'impose rien : c'est la pratique.

Une séance efficace#

1. Préparer : le PO sélectionne 5 à 8 items du haut du backlog et les expose à l'avance.
2. Comprendre : le pourquoi d'abord, puis exemples concrets (mettre des chiffres et des cas réels).
3. Découper : si on ne peut pas dire « ça tient dans un Sprint », on découpe.
4. Critères : formuler les critères d'acceptation, les cas limites, les dépendances.
5. Estimer (si on estime) : rapidement, relatif.
6. Identifier les inconnues : spike nécessaire ? donnée à vérifier ? expert à inviter ?

Combien de backlog « prêt » ?#

Un repère : environ deux Sprints d'items prêts en haut du backlog, ni plus (obsolescence, gaspillage), ni moins (Planning improvisée). Si le haut du backlog dépend de réponses externes (arbitrages métier, accès aux sources), commencez à les chercher avant, car c'est le délai d'attente qui bloque, pas la taille.

🟡 Pratique — Estimation : points, flux, #NoEstimates#

L'estimation est un outil de décision, non un engagement. Son but est de prévoir (à quelle date, avec combien de contenu) et d'éclairer l'arbitrage (rapport valeur/effort). Le Guide dit seulement que les Developers dimensionnent.

1. Points d'histoire (story points)#

On mesure l'effort relatif (complexité, incertitude, volume) et non des heures, avec une échelle discrète (Fibonacci modifiée : 1, 2, 3, 5, 8, 13, 20…) pour refléter l'incertitude croissante.

2. Prévision par le flux (sans points)#

Plutôt que d'estimer chaque item, on mesure le débit (throughput : nombre d'items terminés par période) et le temps de cycle (délai entre « commencé » et « terminé »). Hypothèse : si les items sont découpés à peu près à la même grosseur, compter suffit.

Prévision probabiliste par simulation de Monte-Carlo : on tire au hasard dans l'historique de débit pour simuler N fois le futur, et on lit des percentiles plutôt qu'une date unique.

(Valeurs illustratives, ordre de grandeur.) Avantages : pas de débat de points, peu de réunions d'estimation, résultat honnête sur l'incertitude. Limites : exige un historique, des items de taille comparable, un système stable.

3. #NoEstimates#

Mouvement lancé par Woody Zuill et Vasco Duarte, selon lequel on peut réduire ou supprimer l'estimation d'effort : découper en items petits, mesurer le débit, prévoir par comptage, et se concentrer sur la décision (continuer ou non) plutôt que sur la précision. Ce n'est pas « ne jamais prévoir » mais « ne pas gaspiller de temps à estimer ce qu'on peut mesurer ». Reproche courant : les décideurs veulent une date et un coût avant de commencer ; la réponse est une fourchette et des jalons de réévaluation.

Estimer le travail data : les spécificités#

• Volume et incertitude de la donnée : l'effort dépend moins de la ligne de code que de l'état de la source (qualité, documentation). Un même item « ajouter un champ » peut valoir 1 heure ou 3 jours selon que la donnée existe proprement. D'où l'intérêt d'un spike préalable (Scrum et data).
• Temps machine : une consolidation qui dure des heures n'est pas du temps de travail, mais borne la cadence de test. Estimer l'effort et le délai de traitement.

🟡 Pratique — Vélocité et ses abus#

La vélocité est la somme des points des items Terminés (conformes à la DoD) pendant un Sprint. Une moyenne glissante sur trois à cinq Sprints sert à prévoir la capacité d'un Sprint ou la date d'un backlog estimé.

Usage légitime : prévision à moyen terme par l'équipe elle-même ; détection de dérive (chute soudaine : problème à investiguer, pas à punir) ; calibration du Sprint Planning.

🟡 Pratique — Métriques utiles#

Peu de métriques, lues en tendance, jamais comme objectif individuel. Les métriques de livraison logicielle d'ensemble (DORA) sont présentées dans CI/CD ; le reporting de pilotage dans Métriques et reporting de projet.

Visualisations courantes : burndown (travail restant du Sprint ; sert à voir la dérive, pas à punir), burnup (travail réalisé et périmètre, évite la confusion quand le périmètre change), diagramme de flux cumulé (CFD : révèle les goulets), histogramme de temps de cycle, scatterplot de temps de cycle (items terminés dans le temps avec percentiles).

🟡 Pratique — Definition of Ready contre Definition of Done#

DoR typique : valeur comprise ; critères d'acceptation rédigés ; dépendances connues ; estimable ; tient dans un Sprint ; données de test disponibles. Utilisez-la comme liste de questions (aide à la conversation), pas comme un contrat qui permet à l'équipe de refuser tout item imparfait : le Guide ne la prévoit pas et un DoR trop rigide recrée le cloisonnement prédictif (« vous ne m'avez pas livré une spécification complète »).

DoD typique pour du logiciel : code relu ; tests unitaires et d'intégration passants ; pas de défaut connu bloquant ; documentation à jour ; déploiement automatisé sur l'environnement de recette ; critères d'acceptation vérifiés. Pour la data, voir DoD data.

🟡 Pratique — Planifier un Sprint#

Le déroulé conceptuel est dans Sprint Planning. Voici un canevas opérationnel de 2 heures pour un Sprint de 2 semaines (les durées sont indicatives ; le Guide donne un maximum de 8 h pour un mois).

Règles de bon sens#

• Ne pas surcharger : viser une charge réaliste (par exemple 70–80 % de la capacité brute, ordre de grandeur) ; les imprévus existent toujours.
• Garder du mou pour le support, la dette et les défauts.
• Prévoir des items extensibles : en fin de liste, des items « si on a le temps » (sans les compter dans l'engagement).
• Le Sprint Goal est le contrat, la liste d'items est négociable.
• Si un item déborde : ne pas le « reporter automatiquement » ; re-découper et comprendre pourquoi.

🟡 Pratique — La rétrospective qui change quelque chose#

Le but est décrit dans Sprint Retrospective. Voici comment la rendre utile.

Structure type (60 à 90 minutes pour un Sprint de 2 semaines)#

Formats#

Les cinq causes d'une rétro inutile#

1. Pas d'action ou trop d'actions (>3) jamais suivies.
2. Mêmes sujets chaque fois, sans progrès : la cause est probablement hors du contrôle de l'équipe — le SM doit escalader (voir responsabilités).
3. Manque de sécurité : le manager est dans la pièce, personne ne parle.
4. Format identique indéfiniment : lassitude. Varier.
5. Actions sans propriétaire ni date.

🟡 Pratique — Mettre en place une équipe Scrum#

Préalables#

Séquence de démarrage (4 à 6 semaines)#

Rôles : cumuls et tailles#

Former sans dogme#

La formation (SM, PO, Developers, parties prenantes) est un investissement, mais le coaching sur le terrain compte davantage que la certification (PSM/PSPO de Scrum.org, CSM/CSPO de Scrum Alliance : leur valeur varie selon l'organisme et le formateur ; ce sont des signaux, non des garanties de compétence). Former aussi la hiérarchie : sans sponsors qui acceptent la transparence, l'équipe se heurte à un plafond.

🔴 Expert — Anti-patterns et ScrumBut#

ScrumBut (« Scrum, mais… ») désigne l'adoption partielle ou modifiée qui supprime précisément les parties qui exposent les problèmes (« nous faisons du Scrum, mais nous n'avons pas de rétrospective, parce que… »). Le terme vient de Ken Schwaber et du « ScrumBut test ». Ce n'est pas un jugement sur la souplesse : c'est la perte de la transparence que Scrum est censé produire.

Quand abandonner Scrum#

Scrum n'est pas toujours le bon outil. Signaux : travail de support / maintenance à flux continu et à priorités changeantes à l'heure (Kanban plus adapté) ; équipe d'une personne ; forte contrainte réglementaire où la preuve documentaire prime (hybride) ; absence de PO réel. Un changement de méthode est un acte légitime, pas un échec. Voir Choisir et hybrider et le Comparatif.

🔴 Expert — Scrum à distance#

Les équipes distribuées ou hybrides sont devenues courantes. Scrum fonctionne à distance, mais certaines conditions implicites (communication spontanée, tableau partagé) doivent être rendues explicites.

🔴 Expert — Passer à l'échelle#

Quand le produit dépasse ce qu'une équipe de moins de dix personnes peut porter, on ajoute des équipes sur le même produit. Principe de prudence : ne passez pas à l'échelle avant d'avoir une équipe qui fonctionne ; multiplier une mauvaise pratique multiplie la dette.

Réduire les dépendances plutôt que les coordonner#

Les trois leviers par ordre d'efficacité : (1) éliminer la dépendance (équipes de composants alignées sur la valeur, autonomie de données par domaine) ; (2) la rendre explicite et planifiée (carte des dépendances, contrats d'interface) ; (3) la coordonner (réunions, ponts). Pour une équipe BI qui consomme une source gérée ailleurs, le levier 2 s'incarne en contrat de données — voir Sources et contrats de données.

🔴 Expert — Scrum et contrats#

Le contrat à périmètre fixe, prix fixe, date fixe s'accorde mal avec un cadre où le périmètre varie. Les options, de la plus rigide à la plus souple :

Clauses utiles : définition d'un socle (« Minimum Viable Product ») et d'un périmètre cible ; droit de réordonner le backlog sans coût dans un cadre prévu ; Definition of Done annexée au contrat (qualité contractualisée) ; participation du client (PO côté client) ; conditions de sortie à chaque Sprint ou jalon ; propriété du code et documentation.

Pour une entreprise qui livre son produit à des clients sous forme de kits d'installation versionnés, la contractualisation porte sur la version et le calendrier de livraison ; les évolutions du backlog interne n'ont pas à être contractualisées client par client. Voir Choisir et hybrider pour le raccord avec la gouvernance de version.

🔴 Expert — Trente pièges#

Format : piège → conséquence → remède. Beaucoup sont détaillés plus haut ; la liste sert d'aide-mémoire d'audit (à utiliser en rétrospective trimestrielle).

Autour du backlog et des stories

1. Backlog cimetière → bruit, perte de focus → expiration et suppression.
2. Stories-tâches techniques sans valeur → faux avancement → relier à l'usage ou justifier explicitement.
3. Critères d'acceptation absents → recette conflictuelle → les écrire avant le Sprint.
4. Critères = solution → l'équipe perd son autonomie → décrire le comportement observable.
5. Stories trop grosses → items « presque finis » à la fin → découpage vertical.
6. Estimation de tout le backlog → gaspillage → estimer le haut seulement.
7. Priorités à trois niveaux (haut/moyen/bas) → tout est « haut » → ordre strict.

Autour du Sprint et des événements

8. Sprint sans objectif → liste fourre-tout → Sprint Goal d'abord.
9. Surengagement → échec récurrent, démotivation → capacité réaliste, marge.
10. Changement de périmètre en cours de Sprint sans renégociation → perte de confiance → passer par le PO ; l'objectif prime.
11. Report automatique des items → faux rythme → re-découpage.
12. Daily qui dépasse 15 minutes → sujets détaillés en séance → « parking » puis conversation séparée.
13. Review sans parties prenantes → pas de feedback → inviter, préparer.
14. Rétro sans action ou sans suivi → cynisme → 1–3 actions, propriétaires.
15. Sprint trop long → boucle d'apprentissage lente → raccourcir, découper.

Autour des rôles

16. PO absent → blocages et rework → mandat et temps réservés.
17. PO qui dicte la solution technique → perte de qualité et d'engagement → le PO dit quoi/pourquoi, les Developers comment.
18. SM en chef de projet → équipe passive → rôle de service.
19. Manager qui assigne les tâches → fin de l'auto-gestion → laisser l'équipe se répartir.
20. Équipe à temps partagé fragmenté → coûts de changement de contexte → équipe stable.

Autour de la qualité et de la mesure

21. DoD faible ou variable → dette cumulée → DoD honnête, resserrée en rétro.
22. Sprint de stabilisation → qualité reportée → intégrer tests dans le Sprint.
23. Vélocité en objectif → gonflement → retirer la cible.
24. Comparer les équipes → compétition stérile → comparer des résultats.
25. Métriques d'activité (lignes de code, tickets) → mauvais comportement → mesurer résultats et flux.
26. Dette technique niée → ralentissement → part de capacité dédiée.

Autour de l'organisation

27. Gouvernance prédictive intacte → Scrumerfall → adapter jalons et reporting (voir Choisir et hybrider).
28. Passage à l'échelle prématuré → dette organisationnelle → d'abord une équipe qui marche.
29. Outil avant pratique → process figé par l'outil → pratiques d'abord.
30. Changement non soutenu par la direction → retour aux anciennes habitudes → sponsor qui accepte transparence et auto-gestion.

Les pièges transverses à toutes les méthodes sont dans Pièges et bonnes pratiques.

Métriques : notes /5#

Appréciations d'expert, contextuelles (voir Notation). Contexte : équipe de 5–9 personnes, produit logiciel ou BI à évolution continue. Il s'agit de noter les pratiques de ce fichier, pas Scrum global (voir Scrum, le cadre).

Contribution de l'IA#

Exemples de prompts :

• « Voici une story et ses critères. Liste les cas limites manquants (valeurs nulles, doublons, plusieurs langues, gros volume) et propose pour chacun un scénario Given-When-Then. »
• « Voici l'export des dates de début/fin des 80 derniers tickets. Calcule les percentiles de temps de cycle et propose un SLE. Montre le script. »

Ce que l'IA ne remplace pas : la conversation avec l'utilisateur, la décision de priorité, la compréhension des règles de gestion cachées, la responsabilité de la DoD. Risque spécifique : des stories et des critères plausibles mais faux (règles de gestion inventées) qui passent inaperçus parce qu'ils sont bien rédigés ; et la dette cachée de backlogs abondants que personne ne possède. Voir IA et conduite de projet et IA et outils.

Voir aussi#

• Cadre : Scrum, le cadre ; socle : Fondamentaux.
• Application : Scrum et data ; méthodes dédiées : Méthodes spécifiques à la data.
• Alternatives et hybridation : Agiles et Lean, Comparatif, Choisir et hybrider.
• Livraison : CI/CD, CI/CD pour la data.
• Outils : Planification, Azure DevOps / TFS.
• Matrices : Planification et estimation, Gestion du périmètre et des exigences, Qualité et recette.
• Glossaire : Glossaire.

✻ Rédigé par Claude Sonnet 5.5