Le « Cost of Delay » : l’art de prioriser intelligemment ses users stories

Août 28, 2017
Nicolas Barrail

Dans la vie d’un Product Owner, la priorisation des tâches / user stories est un passage obligatoire, et souvent source de retard car mal appréhendé. Dans cet article destiné aux Product Owners, nous verrons comment optimiser l’ordre de réalisation des stories de façon intelligente, impartiale, ainsi que la manière la plus efficace pour s’assurer d’atteindre l’objectif à tous les coups !

User story : Dans le jargon Agile, la user story représente une fonctionnalité, caractérisée par un utilisateur clef, un élément déclencheur et un effet.

Rappel Méthodologique


Dans la méthode SCRUM, le PO a la responsabilité du produit à développer. Généralement, entouré de « key users », celui-ci créé une multitude de user stories dans le but de décrire toutes les fonctionnalités attendues du produit final, qu’on appelle le « chamallow » (référence au chamallow challenge, animation phare des formations agiles).

Pour atteindre ce chamallow en un minimum de temps, une équipe de développeurs (entre 2 et 5 personnes) prend en charge la réalisation : le code.

Cette équipe de développement suit les consignes du product owner quant aux stories à développer dans chacun des sprints que constitue le projet (la durée d’un sprint varie entre 1 et 3 semaines généralement). Bien que l’équipe de développeurs ait la liberté de s’organiser elle-même dans un même sprint, une chose est certaine: à la fin du sprint, ce sont les user stories sélectionnées par le PO qui devront être mises en production.

L’enjeu est donc crucial car une mauvaise priorisation pourrait entrainer de lourdes conséquences, tant sur l’atteinte de l’objectif (retards, attentes) que sur l’équipe (pressions inutiles, perte de motivation…).

Techniques de priorisation


Plusieurs techniques existent pour prioriser les users stories :

MoSCoW

Initialement, la méthode SCRUM incite le PO à prioriser selon l’unique critère de la Business value : Plus la fonctionnalité est importante d’un point de vue du métier, plus celle-ci doit être développée tôt dans le projet, c’est la méthode MoSCoW. Il s’agit de classer toutes les fonctionnalités selon 4 priorités :
Must : Doit absolument être réalisé
Should : Devrait être réalisé
Could : Pourrait être réalisé
Won’t : Ne sera pas réalisé

La plupart du temps, cela fonctionne, mais pas systématiquement. D’expérience, on retrouve souvent une grande quantité de stories dans les Must, et cela reste un casse-tête pour les départager. De plus, la composante de temps n’est pas du tout prise en compte ici. Une story pourra donc être priorisée en Must alors qu’elle met beaucoup plus de temps que les autres à être développée : Donc bloquant potentiellement d’autres releases.

Ce qui nous manque ici, c’est un critère objectif, capable de nous faire trancher facilement, de manière systématique. Voyons ensemble comment déterminer ce critère, avec la méthode du « Cost of Delay ».

Cost of Delay & CD3

Définition

Littéralement : le coût du retard. Cette méthode consiste à prioriser en fonction d’un critère impartial, appelé « CD3 » (Cost Of Delay Divided by Duration).  Le CD3 permet de quantifier la valeur maximum que représente une fonctionnalité en une période donnée (sprint), et avec une capacité de production limitée (équipe de développement).

Combien me coûterait le fait de ne pas déployer cette fonctionnalité à la prochaine release ? Autrement dit, une fonctionnalité n’apportant que peu de gain, n’est pas prioritaire.
Comprenez bien que lorsque l’on parle de gain, celui-ci se transforme immédiatement en coût si l’on prend du retard.

Ex : une feature générant 100€ de gain par mois, engendre alors 200 € de perte nette si elle dort dans le backlog 2 mois supplémentaires.

Détermination du CoD

Le Cost of Delay s’estime donc en évaluant la valeur que génère la fonctionnalité. Bien entendu, l’euro n’est pas nécessairement la meilleure unité pour quantifier un CoD. La plupart du temps, nous prendrons une échelle de valeur simple pour faciliter l’estimation. Par exemple : 1 (faible), 3 (Moyen), 5 (Fort), 8 (Très fort). Si besoin, il est possible de détailler le calcul en combinant les notes de plusieurs facteurs pour plus de précision.

Ajout de la notion de durée

Une fois que le CoD est appliqué aux features à prioriser, incorporons la notion de durée de développement. En effet, une feature nécessitant 1 semaine de développement sera beaucoup plus vite rentable que celle en nécessitant 3. De la même manière, nous appliquons donc à chaque feature (avec l’aide des développeurs) une estimation en durée de développement : Généralement cela se compte en jours. Attention à utiliser la même unité pour chaque calcul.

Remarque : La durée peut aussi bien être remplacée par la « complexité » (généralement basée sur la suite de Fibonacci), le résultat sera équivalent

Calcul du CD3

Le tout se calcule ensuite alors de la manière suivante :

Plus cette valeur est élevée, plus la fonctionnalité devra être priorisée

Rien de mieux qu’un exemple pour illustrer le tout.


Contexte : Un site internet de vente en ligne doit évoluer pour faire face à la concurrence toujours plus féroce. Plusieurs améliorations sont listées, comment les priorisées ?

# Feature CoD Durée CD3
1 Refonte graphique du site web 8 – Design actuel obsolète, non attractif créant certainement un taux de rebond élevé 10 jours – complexité de développement élevée  8/10 = 0,8
2 Ajout d’un bouton d’achat rapide 1 – Taux d’utilisation estimé assez faible mais ajout d’une fonctionnalité novatrice 2 jours – complexité faible  1/2 = 0,5
3 Campagne e-mailing ciblée et attractive 3 – Taux de visites attendues en hausse, aspect visuel soigné attendu 2 jours – complexité faible  3/2 = 1,5
4 Refonte HTML pour optimiser le SEO et gagner en visibilité 5 – Impact clair sur le nombre de visites via les moteurs de recherche 3 jours – Complexité moyenne  5/3 = 1,7

Une fois ce travail effectué, il suffit de comparer les CD3 pour en déduire une priorisation. Ici : 4 -> 3 -> 1 -> 2

Pour aller plus loin, il peut être pertinent de quantifier précisément le COD, en prenant une hypothèse de coûts : 1 unité de valeur vaut 1000€ / jour (par exemple).
Ex : la fonctionnalité #4 rapporte (ou coûte) 5 x 1000 € = 5 000 € / jour

Partant de ce principe, dans ce scénario le COD est égale à :

  • (5000 + 3000 + 8000 + 1000) x 3 = 51 000 €  Détails
  • (3000 + 8000 + 1000) x 2  = 24 000 €  Détails
  • (8000 + 1000) x 10  = 90 000 €  Détails
  • (1000) x 2  = 2 000 €  Détails

Soit un COD total de 51 000 + 24 000 + 90 000 + 2000 = 167 000 €

En suivant cet ordre de priorité, vous vous assurez donc d’être le plus efficace possible, contrairement aux autres scénarios envisageables, qui ne sont pas toujours les plus pertinents :

  • La fonctionnalité la plus rapidement développée en premier
  • La fonctionnalité avec le plus de valeur en premier
Quid du résultat avec les autres méthodes ?

Le Cost Of Delay peut aussi bien s’appliquer à d’autres domaines comme le portfolio management ou la finance. Utilisée pour la priorisation des user stories, cette méthodologie améliorera drastiquement la cadence de vos déploiements (vitesse), la qualité de vos livraisons (moins d’anomalies) et le coût global de votre projet (coût horaire optimisé).

Alors pourquoi ne pas tenter l’aventure ?

Pas de commentaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *