Prioriser mes développements : A PO Story

« La troisième priorité est de donner la première des priorités à l’enseignement. » : Citation de George W.BUSH

 

Merci George d’avoir introduit avec brio ce sujet Ô combien au coeur de l’entreprise moderne et d’Agile. Mais où est donc Ornicar ?

Heureusement, Larousse nous apporte une autre définition « Prioriser c’est définir une importance préférentielle à quelque chose ». Prioriser c’est donc :

• Estimer la valeur des choses.
• Hiérarchiser cette valeur selon des critères.

 

Alors trêve de littérature et de sémantique et plantons le décor de ce retour d’expérience Xebia :

• Une petite équipe (5 personnes)
• Un délai serré (4 mois, dont 3 de développement, pour sortir un produit commercialisable en partant d’un POC)
• Une typologie client à forte inertie et à faible disponibilité (milieu hospitalier)
• Un projet extrêmement stratégique pour l’entreprise

Estimer la valeur de mes développements

Nous avons fait le choix du poker planning pour estimer nos US afin de nous offrir une échelle de valeur de la complexité technique des US relative. Nous ne nous attarderons pas sur le poker planning dans cet article.

Le poker planning a la faculté de produire une échelle de complexité des différentes stories : plus une story a un score élevé plus elle est complexe à implémenter (volume à produire, risques, dépendances etc …).

Et pourquoi ne pas répéter le même exercice mais avec nos utilisateurs ?

Cette fois-ci, exit la complexité, welcome la valeur ! On procède de la même façon mais on parle valeur utilisateur. Idéalement, un workshop avec des utilisateurs produira une échelle fiable (représentative des besoins), dans notre cas nous les avons remplacés par des experts métier produisant une classification relativement fiable, les experts se faisant la voix des utilisateurs. Néanmoins, un expert ne peut remplacer un groupe d’utilisateurs et j’insiste sur l’intérêt de pouvoir construire ce value poker avec des utilisateurs réels. Plus une story a un score élevé plus sa valeur est importante pour l’utilisateur du produit.

Avec la même méthode de travail nous obtenons alors la vision « Complexité & Valeur » du produit :

Y voir plus clair : le mapping

« J’adore quand un plan se déroule sans accros » résume entièrement cette phase : on déroule (et on colle du post-it). Chaque US devient donc un couple (valeur, complexité) qu’on vient disposer sur un diagramme :

What Else ?

On a un beau tableau, que fait-on ? Et c’est là que la littérature nous perd et que les esprits s’embrasent. Deux théories s’affrontent :

• Quick-Wins : on doit dans Agile délivrer de la valeur rapidement (plus je délivre de la valeur tôt, plus j’obtiens des feedbacks tôt).
• Tech-Wins : on doit délivrer la valeur en dégageant les gros risques techniques en premiers (et éviter à mi-projet des refontes massives).

Et le problème c’est que les deux théories sont justes ! Elles se concentrent en premier sur les hautes valeurs mais s’opposent sur la gestion de la complexité. C’est ainsi que nous avons décidé d’introduire un autre élément pour nous aider à choisir : l’équipe et son environnement.

« Tech-Wins oriented » : « On a des muscles ! On peut s’affranchir des gros risques techniques en premier »

• Equipe mature en Agile (familiarisée avec les concepts d’échec, d’apprentissage, d’incrément etc …)
• Moral de l’équipe positif
• Pressions intra-entreprises sur l’équipe faibles
• Pressions extra-entreprises sur l’équipe faibles

« Quick-Wins oriented » : « On a besoin de se rassurer et de gagner en maturité »

• Equipe immature en Agile (en pleine transformation par exemple, sous coaching, éléments juniors, etc…)
• Moral de l’équipe égratigné (de tendu à « dans les chaussettes »)
• Pressions intra-entreprises sur l’équipe fortes (management, stakeholders etc …)
• Pressions extra-entreprises sur l’équipe fortes (utilisateurs, prospects, concurrence etc …)

Dans les deux cas c’est une décision qui se discute avec l’équipe et les stakeholders. Il s’agit de faire un choix, et le meilleur moyen de s’assurer que ce choix ne génère pas de frustrations c’est le consensus : nous savons où nous allons et pourquoi nous y allons ensemble. Il n’y a pas de règle mathématique dans la sélection d’une des deux priorisations, c’est un équilibre qu’il faudra trouver avec les acteurs. Le plus important reste l’adhésion et d’être honnête sur les risques et avantages des deux approches.

Eut égard à nos paramètres nous avons fait le choix en tant qu’équipe du « Tech-Wins », les hostilités étaient lancées :

• On dépile #1 (forte valeur, forte complexité)
• Puis #2 (forte valeur, petite complexité)
• S’il reste du temps on fera #3 (petite valeur, faible complexité)
• #4 ne devrait pas être fait (petite valeur, grand complexité)

Il faut garder à l’esprit que cette priorisation permet de faire un « classement brut » des priorités, en aucun cas absolu. L’idée est de classer la totalité des stories puis de vérifier la cohérence, une story en #3 peut être importante : dans notre cas une story relative aux contraintes RGPD nous empêchait de pousser la produit en démo sur des sites pilotes : la story a immédiatement été poussée en top de notre liste (même si de faible valeur pour l’utilisateur final).

Il s’agit là d’un outil d’aide pour le PO, mais ce dernier garde la main sur son backlog et la priorisation finale de celui-ci.

Le Check Qualité :

Last but not least : cette approche permet de rapidement effectuer deux checks qualité du projet.

 

Va-t-on dans la bonne direction ?

Une majorité des développements doit être contenue sur la partie droite du cadran (forte valeur) : signe que nous avons identifié des vrais leviers de valeur.

Si un grand nombre de développements se trouvent en zone rouge (Forte complexité / faible valeur) c’est un signal d’alarme : un grand nombre de nos idées n’ont aucune valeur et sont techniquement risquées. C’est le bon moment pour déclencher des ateliers de design thinking (Type Google SPRINT) pour rapidement se remettre en selle, de descendre sur le terrain rencontrer nos utilisateurs etc … Il faut réaligner le produit.

Mon découpage en US est-il correct ?

Dans l’idéal, une majorité d’US complexes n’est pas une bonne chose. Il est plus simple d’accomplir 10 tâches simples que 1 compliquée. C’est un signe pour le SM (Scrum Master) d’engager avec le PO (Product Owner) un re-découpage des US et ainsi abaisser le niveau de complexité général du produit.

---

Cette approche : simple et visuelle nous permet de poser les bases de la priorisation en quelques minutes (que nous retoucherons par la suite) en laissant les émotions et jugements approximatifs de côté. Une story qui n’a pas de valeur n’a pas de sens en priorité 1 (hors cas particulier, pour nous les contraintes RGPD). Le temps passé est consacré à la cohérence d’ensemble du produit plutôt que de débattre sur des abstractions avec le PO.

De plus, le check qualité nous aura permis de valider :

• Que nous allons dans la bonne direction. (dans notre cas sur 60 US, 1 est en #4 zone rouge : elle sera déscopée)
• Que j’alimente mon équipe en tant que PO avec des découpes pertinentes : simplifier = accélérer le Time2Market. (dans notre cas 8 US sur 60 sont jugées complexes : nous attendons de voir quelle vélocité l’équipe peut absorber avant de déclencher une re-découpe)
• S’affranchir de la vision mathématique des points / poids pour visualiser la cohérence d’ensemble du projet et ne pas appliquer « une méthode infaillible ». (nous n’avons pas hésité à re-priorisé des US qui logiquement devaient atterrir en priorité #1 : RGPD)

---