La tenue d’un backlog de user stories est un art dans lequel beaucoup d’équipes agiles excellent. Pourtant, dans beaucoup de ces équipes, la priorisation se basant sur ce backlog est perfectible, toujours dans une démarche d’amélioration continue à la poursuite de plus de valeur pour moins de délai/coût/effort.
Une définition
Dans ce billet, j’entends par priorisation l’action de choisir les user stories du backlog du projet qui seront prises en compte dans l’itération à venir.
Les enjeux de la priorisation
- Une maîtrise des budgets et des délais en développant d’abord les 20% de fonctionnalités qui seront utilisées 80% du temps ;
- Une gestion des risques efficace en maximisant le niveau d’information des acteurs, sur l’adéquation au besoin du code livré et sur les difficultés techniques éventuelles ;
- Une livraison la plus fréquente possible de macro-incréments (les lots) déployables en production et réellement utilisables par les métiers.
Retours d’expérience et tips & tricks
« Avec ces 8 itérations de recul, je me dis qu’on a raté les vraie priorités lors des toutes premières itérations… ».
La priorisation des toutes premières itérations est parfois sous optimale et conduit à prendre en compte des user stories que l’on trouve bien peu utiles après quelques itérations de recul.
Sans retomber dans le le Big Upfront Design, une solution consiste à la mise en place au plus tôt d’un « macro backlog » (ce qui tient parfois de la gageure, dans les projets les plus « pressés »). Ce macro backlog ne détaillera pas toutes les stories mais il jettera clairement les attentes principales du premier lot à venir. Attention toutefois ce macro backlog ne permettra une priorisation que si les macro user stories se voient affecter une « valeur métier ».
« Dès qu’on établit les valeurs métier, j’ai l’impression de comparer des choux et des carottes ».
En ces temps où les projets agiles se multiplient, on découvre des équipes de développement fortement expérimentées sur les pratiques agiles tandis que leur nouveaux clients sont peu habitués à ces nouvelles méthodes. En particulier le product owner est souvent moins expérimenté sur l’évaluation de valeur métier que les équipes métier le sont sur l’évaluation de complexité de développement. Bien sûr les acteurs métier savent mieux que quiconque ce qui leur importe vraiment mais il peut leur manquer des réflexes de comparaison et de priorisation.
Le mode de pensée issue de la cascade et des spécifications détaillées a laissé des traces : dans ce type de planification, tout se valait, à plat, à travers une structure orientée sur des blocs fonctionnels plutôt que sur l’axe valeur.
Dans ce cas, il ne faut pas hésiter à faire un effort comparable à celui fait avec les équipes de développement dans le cadre de la formation au planning poker. La transmission de quelques heuristiques peut faire l’affaire dans un premier temps. Ainsi, on conseillera de valoriser suivant la suite de Fibonacci en s’efforçant d’utiliser des valeurs très disparates (1 pour les stories les plus pauvres…89 pour les plus importantes) pour aider à la mise en perspective entre l’accessoire et le fondamental.
Des exemples bien sentis de priorisations absurdes, sur un domaine métier complétement différent provoquerons souvent le déclic chez le product owner.
« Mince, mon équipe de développement agile était si productive que j’ai relaché mon effort de priorisation ».
La priorisation est parfois la victime collatérale de la productivité des bonnes équipes de développement agile. Ainsi, on observe des projets agiles où la facilité à livrer de nouvelles fonctionnalités met le product owner dans une sorte d’extase : les users stories sont livrées si rapidement qu’on peut se laisser aller à planifier des stories de second ordre, ou alors à en peaufiner très peu jusqu’à la perfection… En sommes on relache le focus sur le BUT.
Rappelons le principe de feed-back projet : en bon gestionnaire de risques, obtenons le maximum de retours fonctionnels et techniques sur les user stories les plus stratégiques, on aurra tout le temps de se « lacher » plus tard si l’équipe est si productive.
« Oulala, je n’ai pas assez de moyen pour maintenir en permanence un backlog bien priorisé ».
Les projets agiles ménagent le plus souvent le cérémonial du planing game, moment privilégié pendant lequel client et développeur interagissent, chiffrent les complexités de développement et planifie l’itération à venir. Certains projets agiles ne ménagent pas encore de cérémonial équivalent pour ce qui est de l’estimation des valeurs métier. Le product owner se retrouve souvent seul (sans échange générateur de nouvelles idées) et doit organiser lui-même cette tâche « off-band », i.e. en dehors des phases prévues systématiquement dans le flot des itérations.
Une planification d’ateliers formalisés de priorisation fera souvent l’affaire. Il s’agira de convier régulièrement plusieurs acteurs métier (dont le product owner) pour valoriser des « macro user stories ». Le formalisme de ces macro user stories doit s’approcher de celui du backlog, mais on relachera certaines contraintes formelles pour fluidifier la participation d’acteurs peu disponibles comme les utilisateurs ou les sponsors.
Conclusion
Pour ceux d’entre vous qui ont fait le pas de l’agilité, rencontrez-vous des difficultés dans la priorisation de vos projets agiles ? Quels axes d’amélioration avez-vous mis en jeu récemment sur ce thème, et quels autres axes envisagez-vous à l’avenir ?
Pour les autres, quelles réflexions vous inspire ce mode de planification ?
3 commentaires sur “Comment mieux prioriser en projet agile”
Les écueils exprimés au travers des questions sont récurrents pour des organisations qui démarrent
dans l'univers des approches agiles. Ceci m'inspire plusieurs réflexions orientées 'Lean' qui je l'espère, peuvent
apporterons des éléments de réponse.
1) Ne rien lâcher, ne pas se décourager : comme tu l'as dit, une organisation apprenante valorise
l'ensemble des évènements (positif, négatif pour le BUT) par la remise en cause de ses standards
(pratiques, procédés et outils) avec pour objectif d'améliorer son système de production. Ces problèmes
sont donc une richesse et doivent être soulevés de manière à améliorer le système :
'Stop the line', 'Root Cause', 'PDCA', les '5s' sont des outils permettant d'aborder de manière structurée
et efficace ce genre d'évènements.
2) Une vue d'ensemble du système, pour une optimisation d'ensemble : vous connaissez l'adage 'rien ne sert de courir ...'.
En effet, des équipes de développement 'trop rapide' face à un des analystes ou un Product Owner sous pression ou le phénomène
inverse ne sont pas bon pour l'ensemble du système et donc pour l'ogranisation. La théorie des contraintes ou des queues nous enseigne à cet gard qu'il faut que les goulots d'étranglements soit repérés, levés de manière récurrente. Dans ce cas, ou l'équipe
d'analyste est sous-dimensionner ou celle de développement est sur-dimensionner. Dans les deux cas, il faut éviter les stocks et/ou
les gaspillages (de code non testé, les fonctionnalités de second ordre mis en priorité 1...). En somme, régler le problème à la racine
du mal, maintenir le flux continue d'informations entre les différentes activités.
3) Product backlog, Iteration backlog, Code Repository: une propriété collective. Le 'Product Owner' (ou 'Champion') est celui qui donne
la vision produit (et du systeme produit qui en découle). Il tranche lorsqu'il a des options possibles. Le backlog est la propriété de
l'ensemble de l'équipe et les phases ou l'on prépare le contenu d'une itération servent à cela. Durant cette étape, un item du 'Product Backlog'
devient 1 ou N story(ies) dans le backlog d'itération. Les élements qui concourent à la priorisation sont nombreux :
* L'expérience collective des itérations précédentes
* Les expériences individuelles du domaine : marché, client, organisation, stratégie produit....
* L'intérêt du client comme point d'entrée : cf. le modèle Kano en.wikipedia.org/wiki/Kan...
* Une mode de pensée incrémentale (que l'on oublie souvent)
MAC
Marc,
j'aime bien ton idée d'identifier les goulets d'étranglement dans la démarche de priorisation.
Si je reformule, un product owner ayant peu de disponibilité est un goulet potentiel du processus de priorisation.
Attention toutefois, le processus de priorisation est plus complexe qu'une chaîne de production industrielle. Dans cette dernière la recherche de goulet passe notamment par des mesures du throughput. Or dans le cas de la priorisation le throughput est piégeux : il ne s'agit pas seulement de la vélocité (throughput de delivery) mais aussi et surtout du throughput de VALEUR.
Un des points de mon billet c'est qu'on se contente parfois du throughput de delivery, au risque de ne pas voir émmerger les goulets sur le throughput de valeur.
Tu as raison de distinguer débit de fonctionnalités du débit de valeur. Mais la valeur est si difficile à mesurer ! C'est pourquoi on discute beaucoup plus de coûts, plus simplement mesurables : combien coûtera d'ajouter un tri par groupe ? combien coûtera de pouvoir gèrer deux devises ? ...
Pour maximiser la création de valeur, il faut développer une dialectique. Qu'est-ce qui crée de la valeur dans une entreprise ou l'on introduit de l'informatique ? Trois axes : cela diminue les coûts (63% des factures sont traitées automatiquement ..), cela augmente le chiffres d'affaires (on a sorti le produit corporate+ en 2 mois, il génère 12% de notre CA après 6 mois) ou cela diminue les risques (les rapports financiers sont fiables et auditables). Chaque entrée dans le carnet de commandes doit pouvoir se justifier par cette dialectique : si je ne la fais pas, vais-je perdre une, deux ou trois de ces opportunités ?
Enfin, ne soyons pas manichéen. Cette dialectique fonctionne parfaitement dans un contexte établi. En contexte fortement innovant, elle est possible, mais soumise aux probabilités : écoutez, je pense que cela peut génèrer 2 point de CA dans les 2 ans, mais bon, c'est une intuition ? 50% ... Dans ces conditions, il faut simplement définir l'intention, l'objectif et se concentrer sur le plus court chemin qui mène en production : par exemple 'délivrer un site Web qui permet de sélectionner des entrepreneurs de micro-crédit et faire payer les internautes'. Plus c'est flou, plus il faut livrer vite