Backlog et stories d'équipe

Dans SAFe, le travail suit une hiérarchie :

Epic → Fonctionnalité → Story

• Les Epics sont de grandes initiatives qui s'étendent sur plusieurs PI. Ils vivent dans le Kanban de portefeuille et nécessitent des analyses de rentabilisation Lean.
• Les Fonctionnalités sont des incréments de fonctionnalité qui apportent de la valeur à l'utilisateur. Elles vivent dans le backlog de programme et sont dimensionnées pour tenir dans un seul PI. La gestion de produit détient la priorité des fonctionnalités.
• Les Stories sont de petits éléments de travail implémentables qu'une équipe peut compléter dans une itération. Elles vivent dans le backlog d'équipe. Le Product Owner détient la priorité des stories.

Le flux de décomposition : la gestion de produit décompose les epics en fonctionnalités pendant la planification de PI. Les Product Owners décomposent les fonctionnalités en stories pendant la planification d'itération (et les sessions de raffinement).

Les bonnes stories suivent les critères INVEST :

• Indépendante — Peut être développée sans dépendre d'autres stories
• Négociable — Les détails sont discutés, pas dictés
• Valuable — Apporte une valeur claire à l'utilisateur ou au système
• Estimable — L'équipe peut estimer l'effort
• Small — Tient dans une seule itération
• Testable — Critères d'acceptation clairs

Tous les travaux n'apportent pas de valeur directe à l'utilisateur. Les Enablers sont des stories (ou des fonctionnalités, ou des epics) qui construisent la fondation technique pour les capacités futures.

SAFe définit quatre types d'enablers :

Enablers d'architecture : Construisent la piste d'atterrissage architecturale — services partagés, API, infrastructure dont les fonctionnalités futures auront besoin. Exemple : mettre en place un système de file d'attente de messages avant de construire des fonctionnalités événementielles.

Enablers d'infrastructure : Mettent en place l'infrastructure de développement, de test et de déploiement. Exemple : créer un pipeline CI/CD, mettre en place la surveillance, provisionner des environnements.

Enablers d'exploration : Explorent les options et réduisent l'incertitude. Exemple : prototyper deux approches différentes pour voir laquelle performe mieux, stories de spike.

Enablers de conformité : Satisfont les exigences réglementaires ou politiques. Exemple : implémenter la journalisation d'audit, le chiffrement des données ou les normes d'accessibilité.

Gérer les enablers dans le backlog :

Les enablers se disputent la capacité avec les stories de fonctionnalités. Une équipe en santé consacre environ :

• 70-80 % aux stories de fonctionnalités (livraison de valeur directe)
• 20-30 % aux enablers (piste d'atterrissage architecturale, dette technique, infrastructure)

Ce ratio n'est pas rigide — il dépend de la maturité du système. Les nouveaux produits nécessitent plus de travail d'enabler ; les produits matures peuvent pencher vers les fonctionnalités. La clé est de rendre le travail d'enabler visible plutôt que de le cacher.

Pendant la planification d'itération, les équipes déterminent la quantité de travail à laquelle elles peuvent s'engager :

Capacité = membres d'équipe disponibles × heures par jour × jours dans l'itération, moins les réunions et les interruptions connues. Les équipes apprennent leur capacité réelle par l'expérience — c'est une mesure empirique, pas un calcul.

Les story points estiment la complexité relative. Les équipes se calibrent avec le temps. La métrique clé est la vélocité — les story points moyens complétés par itération. La vélocité se stabilise après 3-4 itérations et devient un outil de planification fiable.

Engagement dans le contexte SAFe :

Les engagements d'équipe dans une itération s'alignent avec les objectifs de PI établis pendant la planification de PI. L'objectif d'itération devrait correspondre au progrès sur un ou plusieurs objectifs de PI. Cela crée un alignement traçable du travail d'équipe à la valeur du programme.

Lorsque les équipes découvrent en milieu d'itération qu'elles ne peuvent pas tenir un engagement :

1. Communiquer immédiatement (transparence)
2. Travailler avec le PO pour ajuster la portée (négociation)
3. Remonter au RTE si cela affecte d'autres équipes (coordination)
4. Ne jamais sacrifier la qualité pour respecter une date (qualité intégrée)

La mesure de prévisibilité : SAFe suit à quel point les équipes livrent leurs objectifs de PI. Il ne s'agit pas de punir les échecs — il s'agit d'améliorer la précision de l'estimation et de la planification au fil du temps. Une équipe qui livre de manière fiable 80 % de ses objectifs est plus précieuse qu'une qui promet 100 % et livre de manière imprévisible.