Points de Story normalisés dans SAFe – comment et pourquoi ?

SAFe4 propose que les Story Points soient standardisés au sein du développement produit à travers les différentes équipes. Pour cela, SAFe offre une méthode permettant d'estimer les Story Points dès le tout premier Sprint. Du point de vue de Scrum, cette approche semble d'abord incohérente avec l'idée des Story Points. Pour résoudre cette contradiction, examinons cette idée de plus près.

Qu'est-ce que les Story Points au juste ?

Les Story Points sont, en bref, une mesure arbitraire pour quantifier l'effort d'un élément du backlog. Ils doivent aider les développeurs à mieux planifier leur capacité – et au Product Owner à comprendre ce qui est réalisable dans les semaines et mois à venir. Cela permet par exemple de prévoir les dates et le périmètre d'une release.

Un avantage supplémentaire est proposé par Mike Cohn : si tu connais la Velocity et les coûts mensuels d'une équipe, tu peux estimer les coûts des éléments du backlog. Cela permet d'optimiser la rentabilité du développement. Par exemple, un élément du backlog peut sembler non rentable une fois les coûts connus. Ainsi, le Product Owner peut décider rapidement si une Story doit être retravaillée ou complètement abandonnée.

SAFe reprend cette idée dans le concept WSJF : les Features avec le meilleur rapport coût-bénéfice devraient être priorisés.

Le plus important pour que cette approche fonctionne est que tous les participants aient la même compréhension des Story Points. Comme les Story Points peuvent signifier des choses légèrement différentes selon les équipes, il faut être prudent lorsqu'on examine ces valeurs en dehors de l'équipe.

Que sont les Story Points Normalisés ?

Dans SAFe, l'unité de développement pour le produit est un Agile Release Train (ART), une « équipe d'équipes ».

Tout comme il est important dans Scrum que tous les participants de l'équipe comprennent un Story Point de la même façon, il est tout aussi important dans SAFe que tous les participants de l'ART partagent la même compréhension d'un Story Point.

Si les équipes interprétaient les Story Points différemment, le Product Manager obtiendrait des estimations complètement différentes selon l'équipe qui a estimé un élément. Les estimations ainsi obtenues seraient totalement inutilisables d'un point de vue métier. Tout le processus d'estimation deviendrait inutile et les estimations n'auraient aucune valeur.

C'est pourquoi SAFe recommande que, tout comme une compréhension commune des Story Points est nécessaire au sein d'une équipe Scrum, les différentes équipes de l'ART ont également besoin d'une compréhension commune des Story Points pour estimer de manière pertinente.

Pourquoi les Story Points individuels par équipe ne sont-ils pas une bonne idée ?

Dans SAFe, toutes les équipes de l'ART partagent un seul et même Program Backlog centralisé. Ce Program Backlog consolide l'ensemble des activités de l'ART, indépendamment de l'équipe qui prendra effectivement le travail en charge par la suite.

Un concept clé de l'agilité est que le travail devrait être indépendant des personnes, car la spécialisation mène à une optimisation locale.

D'un point de vue Lean, il est souvent préférable qu'une équipe plus lente commence immédiatement le travail, plutôt que d'attendre l'équipe plus rapide pour des choses importantes.

Particulièrement lorsque plusieurs équipes collaborent, une équipe plus lente peut souvent déjà livrer une partie de la valeur avant que l'équipe plus rapide ne soit disponible pour participer. Cela réduit le temps total de livraison et l'engagement de l'équipe plus rapide jusqu'à l'achèvement final.

Si les Story Points diffèrent entre les équipes, chaque élément du Backlog doit être estimé par chaque équipe individuellement, jusqu'à ce qu'on comprenne quelle équipe pourrait terminer quand. C'est bien sûr possible, mais cela représente un gaspillage et un overhead considérables.

En revanche, si les Story Points sont normalisés entre les équipes, une seule estimation d'une seule équipe suffit. En regardant ensuite la vélocité des différentes équipes, on voit rapidement et facilement combien de temps cela prendrait.

Un avantage supplémentaire des Story Points normalisés : si l'équipe A a besoin du soutien de l'équipe B pour respecter une deadline importante, le Product Owner de l'équipe B sait immédiatement combien l'équipe B devrait retirer de son Backlog pour prendre en charge les Stories de l'équipe A. Comme aucune nouvelle estimation n'est nécessaire, il n'y a ni délais ni efforts d'estimation supplémentaires.

Comment SAFe normalise-t-il exactement les Story Points ?

Lors du tout premier Program Increment, l'ART est nouveau. Ni les équipes individuelles, ni les personnes au sein de l'ART n'ont jamais travaillé dans cette constellation exacte. Les équipes se trouvent dans la « phase de Storming » – tout comme l'ART lui-même.

Cela signifie que les Working Agreements ne sont pas encore clairs. La DoD est un idéal flou qui n'a encore jamais été testé en pratique. Des obstacles peuvent se trouver partout. Selon l'avancement du développement produit, l'environnement de travail est probablement aussi nouveau et inconnu. Tout le monde se trouve en terra incognita – chaque estimation relève de la divination.

Une approche possible serait de discuter ensemble de quelle Story choisir comme référence, comment définir les points, combien de points attribuer à la Story de référence – puis de partir de là. Cette discussion mènera à d'autres discussions, qui en elles-mêmes n'apportent aucune valeur du point de vue client.

SAFe évite cette approche et propose ce qui suit : l'estimation relative

Lors du tout premier PI Planning, on commence par sélectionner le plus petit item du backlog de l'équipe et on lui attribue un « 1 ». À l'item suivant en taille, on attribue un « 2 », et on progresse en utilisant une suite inspirée des nombres de Fibonacci (1,2,3,5,8,13,20,40,100) : avons-nous un item de la même taille qu'un item connu ? Si oui, il reçoit le même nombre – s'il est le plus grand jusqu'ici, il reçoit un nombre approprié. Si nous n'avons pas de bonne référence et devons faire un saut, « 3 » serait au moins deux fois plus grand que « 1 », et « 8 » au moins deux fois plus grand que « 3 », etc. Ainsi, grâce à une démarche très simple et sans connaissance précise, on peut se faire une idée de ce qui attend l'équipe.

C'est bien sûr une estimation pure et les valeurs sont assez imprécises. Mais puisque nous n'avons pas encore de données d'expérience, cette approche est aussi valable que n'importe quelle autre. Le plus important est que les équipes discutent du « Quoi », du « Pourquoi » et des risques potentiels concernant les Stories.

Comment la Velocity est-elle calculée à partir des Story Points normalisés ?

Pour le souligner une fois de plus : lors du premier Program Incrément, nous n'avons aucune idée du nombre de Story Points qu'une équipe peut réellement accomplir. Cependant, comme nous disposons d'estimations en PT, SAFe propose l'approche suivante pour le premier PI Planning :

Nous savons combien de membres compte notre équipe. Nous savons aussi combien de jours nous prévoyons de venir travailler pendant une itération (bien sûr, on ne sait jamais quand on va tomber malade – ce risque demeure).

Une itération SAFe typique dure 2 semaines calendaires, soit 10 jours ouvrables. On peut multiplier ce nombre par le nombre de membres de l'équipe :
Base Capacity = 10 * Team Members

Ensuite, nous déduisons les jours où les membres de l'équipe sont absents :
Capacity ajustée = Base Capacity – (jours fériés * Team Members) – (jours d'absence individuels)

Nous retirons encore 20 pour cent – car planifier à 100 pour cent de charge mène toujours au désastre !
Velocity initiale = Capacity ajustée * 0.8

Voici un exemple :
L'équipe Trolls est composée de 6 développeurs. Il y a un jour férié lors de la prochaine itération et Toni doit régler quelque chose de personnel le vendredi.

Base Capacity = 106 = 60 SP
Capacity ajustée = 60 SP (Base) – 16 SP (jours fériés) – 1 SP (absence) = 53 SP
Velocity initiale = 53 SP * 80 pour cent = 42 SP

L'équipe Trolls planifierait alors l'itération 1 avec 42 Story Points. Si les chiffres des Stories ne correspondent pas exactement, il vaut toujours mieux rester un peu en dessous que de se surcharger. Les Trolls pourraient donc décider de démarrer la première itération avec 39 SP.

Qu'arrive-t-il aux Story Points normalisés au fil du temps ?

Lors de la première itération, nous avons simplement deviné. Deviner, c'est mieux que rien. Et ensuite, Inspect+Adapt entre en jeu. Peut-être que les Trolls ont appris qu'ils traversent le backlog comme un couteau chaud dans du beurre. Ils prendraient alors naturellement quelques Story Points de plus la prochaine fois. Peut-être que les Badgers ont appris qu'ils doivent beaucoup aider les autres équipes (comme le transfert de connaissances par exemple). Ils ne prendraient alors plus autant de Story Points à l'avenir.

Voici comment la vélocité de l'ART pourrait évoluer au fil du temps :

Comme nous le voyons dans cet exemple, les équipes utilisent l'Inspect+Adapt individuel et contrôlent leur propre Velocity. Le Product Manager reçoit régulièrement du feedback pour adapter la planification globale du produit et les objectifs PI (ainsi que, le cas échéant, les objectifs de release).

Les réestimations d'éléments de backlog précédemment estimés disparaissent. Lorsque de nouveaux sujets apparaissent, les Stories « Done » peuvent servir de référence pour estimer les futurs éléments du backlog de manière cohérente avec les éléments existants et passés. Le lien avec le jour-homme disparaît.

Attention aux Story Points Normalisés

Les Story Points ne sont pas une métrique business ! La Velocity non plus. Ce sont des métriques de planification simplifiées qui minimisent l'effort de planification tout en donnant une confiance suffisante dans la faisabilité.

Ces métriques sont soumises aux mêmes limitations dans l'ART que dans le Scrum mono-équipe. Les antipatterns suivants doivent être évités.

En aucun cas tu ne dois :

• Considérer les estimations comme « correctes ». Ce sont – et restent – des estimations.

• Mesurer la progression par les « Story Points livrés ». Les produits utilisables sont la métrique de progression principale !

• Comparer les équipes sur la base de leur Velocity. La Velocity n'est pas une métrique de performance !

• Optimiser la structure de l'ART en fonction des valeurs de Velocity. Un ART est un système adaptatif hautement complexe !

• Essayer de maintenir la Velocity constante ou en hausse. La planification de capacité sert à minimiser les risques. Elle est soumise à la réalité. La Velocity n'est qu'un indicateur qui améliore la fiabilité de la planification !

Quand devrait-on utiliser des Story Points normalisés ?

La normalisation des Story Points résout un problème qui n'existe tout simplement pas sans mise à l'échelle. Elle répond à la question « Que se passe-t-il si d'autres équipes travaillent sur cette story ? » Pour cela, la compréhension d'un Story Point doit être uniforme au-delà des frontières des équipes.

Ainsi, dans l'ART, les éléments du Backlog peuvent être relativement facilement déplacés d'une équipe à l'autre, afin de maximiser la valeur globale du produit livré plutôt que la charge de travail des équipes individuelles.

En attendant que de meilleures informations soient disponibles, on peut obtenir un bon aperçu avec un benchmark très simple et une estimation relative. Parmi les stories terminées, on peut ensuite choisir des stories « correctement estimées » et faciles à retenir comme référence pour l'avenir. Il n'y a pas de réestimation. Le lien initialement supposé entre Story Points et jours-personnes disparaît en très peu de temps. Cela doit se produire pour que les Story Points restent cohérents entre les équipes.

Pour la planification initiale de la vélocité également, nous utilisons en l'absence de meilleures informations la règle empirique très simple de « 80 pour cent du temps disponible ». Dès que la première itération est terminée, nous utilisons le résultat réel comme référence pour l'avenir et nous nous adaptons de manière adaptative. En quelques itérations, la corrélation entre la vélocité et la capacité temporelle se dissout également. Cela aussi doit se produire pour que la vélocité puisse être utilisée de manière cohérente et pertinente comme outil de planification dans l'ART.

Dans l'ART, il est encore plus difficile que dans le Scrum en équipe unique de résister à la tentation d'évaluer les équipes en fonction de leur vélocité. Le RTE a la tâche importante de garantir l'intégrité des Story Points en empêchant toute tentative (généralement de la part du management) de détourner les Story Points ou la vélocité de leur usage prévu.