Agilité et maîtrise des risques

Quand une difficulté à estimer cache un risque technique...

Nous avions aujourd'hui une séance d'estimation pour le projet IceScrum2.0. Une cinquantaine d'histoires d'utilisateur déjà réalisées dans la première version client lourd Java sont à porter dans un environnement J2EE.

La technique d'estimation utilisée est le Planning Poker. Nous examinons les histoires une par une. Nous arrivons à l'histoire "ordonner les items de backlog par priorité". Avec la version courante en client lourd, cela est réalisé par drag and drop. Avec un client léger, le drag and drop nécessite d'utiliser des technos Web2.0 comme Ajax. Je vois lors de l'évocation du drag and drop des hésitations sur les visages. On sent que l'estimation est difficile. Lors de la discussion sur cette histoire, AlexLeKid, le ScrumMaster, résume la position de l'équipe :

si on arrive à faire facilement le drag and drop c'est 3 points sinon on ne sait pas trop mais c'est au moins 8.

L'équipe préfère dans ce cas noter une estimation à 8 points et ce n'est pas très satisfaisant d'autant que cela s'est répété sur d'autres histoires.

A la réflexion, et comme le décrit le toujours très pertinent Ron Jeffries dans Risk Management, cette difficulté à estimer cache un risque technique. Ici la faisabilité du drag and drop. La proposition de Ron Jeffries est de créer une histoire supplémentaire et de lui donner une grande priorité. Dans notre cas, ce serait "Evaluer la difficulté à faire du drag and drop et estimer les histoires qui en ont besoin".

L'équipe IceScrum avait par ailleurs établi une liste des risques dans laquelle ce risque ne figure pas. Cela montre un intérêt supplémentaire de cette technique d'estimation individuelle des histoires : elle permet d'identifier clairement un risque réel. Et si on associe ce risque à une histoire qu'on ajoute au backlog, sa prise en compte dans une itération permettra de le gérer et de le réduire. A la fin de l'itération, on devrait savoir estimer correctement les histoires avec drag and drop, voire, si le résultat montre que c'est coûteux à réaliser, décider de s'en passer.

Sur le sujet, lire aussi l'article de Thierry Cros : Etre Agile face aux risques