En amont de la lecture de cet article, je vous invite à lire les deux précédents :
- Ecrire, Découper et Prioriser des User Stories – Chapitre 1 : Ecrire
- Ecrire, Découper et Prioriser des User Stories – Chapitre 2 : Découper
Pourquoi prioriser ses User Stories ?
La philosophie de l’agilité est de fonctionner avec l’incertitude et la complexité.
Les projets agiles ont une vision, savent quels besoins le produit qu’ils développent doit couvrir mais laissent la porte ouverte, au fur et à mesure, à : des besoins émergents, un apprentissage continu sur la meilleure manière de répondre à ces besoins (grâce aux retours réguliers des utilisateurs et la maîtrise progressive des outils de progression) qui imposeront une adaptation du plan initial.
Ajouté à cela, l’agilité admet qu’un sujet soit de plus en plus complexe à mesure qu’on l’étudie et que les choses prennent plus de temps que prévu.
Pour éviter de se perdre au milieu de tous ces changements, l’agilité amène trois pratiques fondamentales.
La démarche itérative pour revoir régulièrement ce qui a été fait et ce qui arrive pour réajuster le plan au mieux
Le découpage pour avancer par petits pas, créer les lots fonctionnels les plus petits possibles pour tester le plus rapidement possible et s’adapter le plus rapidement possible (voir l’article sur le sujet)
Et…
Prioriser les sujets
Face à l’incertitude, l’agilité suggère aux projets de s’appuyer sur des piliers maîtrisables : le coût du projet et le délai de livraison.
Les acteurs feront de leur mieux pour livrer, dans ce cadre, le meilleur produit possible, c’est-à-dire celui qui aura pris en compte les besoins émergents, aura tiré parti des apprentissages apportés de façon itérative et aura maintenu le nombre d’anomalies présentes au plus bas (le tout en respectant le rythme des personnes présentes sur le projet).
Triangle des contraintes agile
Dans ce nouvel espace, comment ne pas se perdre, partir dans tous les sens au gré des retours, des nouvelles demandes ? Comment s’assurer qu’à la date de livraison prévue, le produit soit cohérent, utile, utilisable et utilisé ?
En priorisant. C’est-à-dire en mettant tout en œuvre pour, qu’au plus tôt, les éléments les plus importants soient produits, vérifiés, confirmés.
Comment prioriser ses User Stories ?
La priorisation a toujours lieu en deux phases :
- Une priorisation métier au cours de laquelle les besoins sont priorisés. Qu’est-ce qui est le plus important à apporter aux utilisateurs en premier ?
- Une priorisation pragmatique. C’est-à-dire une priorisation qui s’appuie sur les contraintes réelles : coût de réalisation, impossibilité de démarrer un sujet avant d’en avoir fait un autre avant, disponibilité du matériel ou de la compétence
Priorisation métier, valorisation de la User Story
Dans quelle mesure, tel ou tel sujet mérite d’être traité en premier ?
La priorisation logique, celle consistant à « prendre les choses dans l’ordre » et construire son produit comme nous construirions une maison est souvent la plus traître.
Exemple : pour un site e-commerce, qu’est-ce qui est le plus important ? La page d’accueil censé être la première page du site ou la fiche d’un produit ?
Toute logique indique que la page d’accueil est la première chose à faire pour construire son site, comme la porte d’entrée de la maison une fois les premiers murs montés.
Or c’est bien la page produit qui doit être faite en premier. Pour plusieurs raisons :
- c’est elle qui poussera les clients à acheter ce qui les intéresse. La page d’accueil offre une promesse plus qu’une information d’achat, il est donc fondamental de vérifier que la page produit est bien conçue,
- statistiquement, la majeure partie des utilisateurs arrivent sur les pages produits non pas par la page d’accueil mais par les moteurs de recherche
Quelle est donc la valeur d’une User Story, la valeur métier ?
Pour effectuer une priorisation métier, il est fondamental de réfléchir aux critères de priorisation des besoins utilisateurs et entreprise plutôt qu’à une logique d’ordre évident de construction.
MoSCoW, une pratique de priorisation métier
MoSCoW
Probablement la pratique la plus répandue pour prioriser. Cette technique de priorisation provient d’une méthode agile appelée Dynamic Systems Development Method (DSDM). Dans DSDM, la notion de timebox est centrale pour faciliter la priorisation : « à cette date, que devrions-nous avoir réalisé ».
Must : Cette User Story est absolument fondamentale pour que le produit commence à être utilisé et nous apporte des feedbacks en utilisation réelle le plus tôt possible. Si cette User Story n’est pas livrée, la livraison sera considérée comme un échec
Should : Cette User Story est aussi fondamentale mais pas nécessaire pour l’échéance à venir, elle peut attendre un peu plus longtemps
Could : Cette User Story apporte une amélioration de l’expérience des utilisateurs ou permet de rendre un service utile mais non nécessaire pour l’échéance à venir
Wouldn’t/Won’t : Cette User Story a été acceptée comme élément non critique, peu rentable ou non approprié pour l’échéance. En conséquence, l’US est mise de côté.
Le “o” étant là comme moyen mnémotechnique.
| Attention
Le fait de mettre en perspective l’importance d’une User Story et une échéance ne signifie pas qu’il faut étudier la capacité de réalisation de la User Story pour savoir si elle est prioritaire. |
Retrouvez d’autres techniques de priorisation
- Extrême Valorisation
- Priorisation 20/20
- Buy a Feature (le tableau Klaxoon en super bonus)
Identifier les critères
Une bonne pratique de l’agilité est d’utiliser ces techniques de priorisation à partir de critères.
Ces derniers permettent de se poser les bonnes questions et de ranger les User Stories.
Par exemple :
- Répond aux besoins de façon primaire
- Effet levier sur XX (augmentation du nombre de contrats, amélioration de la connaissance client, transformation financière)
- Existence et qualité de solutions de contournement
Pour une refonte, des critères similaires enrichis de l’étude de :
- Niveau d’utilisation de la fonctionnalité actuelle
- Levier sur XX par rapport à l’existant
- Pérennité de la solution actuelle comme solution de contournement temporaire
Il est possible et recommandé d’identifier plusieurs critères sans non plus tomber dans une trop grande complexité de calcul. 3 critères maximum permettent de prendre les décisions autrement.
Pour identifier rapidement vos critères, en amont il est indispensable de définir :
- La vision de votre produit
- Les objectifs
- Les critères de succès
Ils fourniront le point de départ pour vérifier ce qui est vraiment attendu de la part du produit.
Une fois les critères définis, il sera possible de faire, par exemple, un MoSCoW par critère : « selon cet objectif, cette User Story est-elle indispensable/MUST ? »
| Le coût du délai
Dans son livre “The Principles of Product Development Flow” Don Reinertsen, consultant ayant beaucoup fait pour la compréhension des flux et des systèmes, parle de la notion de coût du délai (Cost Of Delay). Le coût du délai est l’impact du temps sur la valeur d’une User Story (dévaluation progressive, manque à gagner à ne pas sortir tout de suite le service, dépassement d’une date fondamentale pour le business…) Plus d’informations sur le sujet ici : Article de coach-agile.com |
Priorisation réaliste
Valoriser chaque User Story et ainsi fournir une priorisation d’un point de vue métier est une première étape fondamentale mais, évidemment, ne garantit pas que les sujets pourront être traités dans cet ordre. Disponibilité d’un composant, disponibilité d’une compétence, opportunité potentielle en prenant les sujets dans un autre ordre… sont autant de critères à prendre en compte pour maximiser la construction du produit.
L’enjeu est donc de trouver un équilibre dans la priorisation pour s’assurer de livrer ce qui est le plus important pour les utilisateurs et le plus pertinent opérationnellement.
ROI
Une fois le coût récupéré nous pouvons analyser la priorité par son Retour sur Investissement (ou ROI : Return On Investment) et ainsi aller chercher les User Stories à forte valeur ajoutée pour les utilisateurs et faible coût et questionner les User Stories à valeur moyenne et fort coût de production.
Contraintes
Ensuite, il existe une grande variété de contraintes possibles qui peuvent empêcher d’engager rapidement une User Story à forte valeur ajoutée. Il est dès lors fondamental que le ou la Product Owner et toute personne participant aux arbitrages de priorisation aient un échange régulier avec les acteurs et actrices de la mise en oeuvre afin d’identifier les risques et opportunités à traiter un sujet avant l’autre :
Opportunités :
- Réutilisation de briques
- Disponibilité d’un service permettant d’accélérer le développement sur un pan fonctionnel
- Réduction de la complexité et apprentissage en initiant un petit sujet moins prioritaire permettant de poser les bases avant d’engager un sujet de plus grande envergure
Risques :
- Indisponibilité de la compétence
- Besoin de briques en cours de réalisation
Notes : Pour aller plus loin dans la réflexion, identifiez dans le coût, le coût de conception fonctionnelle. Au moment de réfléchir à un nouveau service, combien de temps, combien de compétences sont nécessaire pour valider une conception (règles de gestion, UX…). Certains services nécessitent un développement technique simple mais une grosse charge de conception fonctionnelle.
