Du bon usage des priorités pour les exigences

Dans un développement traditionnel, les clients renâclent quand on leur demande de définir les priorités de leurs exigences. Si on insiste ils ont tendance à dire que tout est prioritaire.

En fait ils ne comprennent pas à quoi ça sert [1]. Dans une approche agile, l'utilisation des priorités devient concrète.

J'ai vu de nombreux documents d'expression des besoins (EB) dans lesquels on trouve des attributs associés aux besoins exprimés. Généralement on a comme attributs priorité, stabilité, criticité avec 3 valeurs possibles pour chaque.
Mon expérience est qu'on on trouve 1 (priorité max) pour 90 % des besoins. Souvent si c'est 1 pour priorité c'est aussi 1 pour stabilité et criticité. Ce qui n'aide pas beaucoup... Le client a l'impression que s'il ne définit pas son besoin comme prioritaire il ne l'aura pas à la fin du projet.
Dans une approche agile, c'est le directeur produit [2] qui définit les priorités. Plutôt que donner une valeur parmi 3, il ordonne la liste des exigences de la plus prioritaire à la moins prioritaire. Dire que A est plus prioritaire que B signifie que A sera réalisé [3] avant B. C'est parce que les priorités sont utilisées pour définir le contenu des itérations.
Je viens de faire l'exercice pour la version 3 d'IceScrum, pour laquelle je suis le directeur de produit. Le backlog contenait 35 exigences.
Ce travail doit être fait avant d'estimer chaque exigence. Cela permet lors de l'effort collectif d'estimation fait par l'équipe, de traiter en premier (et donc d'y passer le plus de temps) les exigences qui vont être développées dans les premières itérations.
Cela permet aussi au directeur produit d'avoir une meilleure connaissance de la valeur des exigences puisqu'il a dû y réfléchir de façon individuelle pour les classer par priorité. Lorsque la release a une date cible fixée, on pourra estimer à quel endroit de la liste des exigences (classées par priorité) on pense arriver. Pour IceScrum, la date cible est fixée au 31 juillet et l'estimation actuelle est d'avoir pour cette date les 21 premières exigences (sur 35).

Notes

[1] la plupart du temps ça ne sert à rien

[2] product owner

[3] et donc fourni au client

Commentaires

1. Le lundi 19 juin 2006, 22:03 par Oaz

"Ce travail doit être fait avant d'estimer chaque exigence. Cela permet lors de l'effort collectif d'estimation fait par l'équipe, de traiter en premier (et donc d'y passer le plus de temps)les exigences qui vont être développées dans les premières itérations."

Ca se discute. Le directeur de produit, voyant le cout élevé de telle ou telle exigence ne peut-il pas décider que, en fin de compte, on peut baisser la priorité d'un truc intéressant mais cher et faire remonter plusieurs autres trucs à peine moins intéressants mais beaucoup plus abordables en terme de cout ?

2. Le lundi 19 juin 2006, 22:53 par claude aubry

Oui, bien sûr. Les priorités définies préalablement peuvent être modifiées lors de la planification avec l'équipe.

C'est arrivé vendredi lors de la planification de la release 3 d'IceScrum. L'item "pouvoir associer des fichiers externes" a été estimé à 8 points. Il entrait tout juste dans la release. J'ai préféré baisser sa priorité pour faire passer 3 items à 2 ou 3 points, ce qui fait qu'il n'est plus prévu dans le planning actuel de la release.