Comment mieux prioriser en projet agile

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 ?