Estimation de l'effort des features

L'usage courant est de définir un élément du backlog de produit comme étant une story. Dès qu'on sort de la toute petite échelle, on a besoin d'un élément de plus haut niveau, habituellement c'est la notion de feature qui y répond.

Pour bien comprendre cette distinction, le mieux est de s'appuyer sur un exemple ; c'est que j'avais essayé de présenter dans le billet Features et stories écrit en août 2010.

Quand on commence le développement d'un nouveau produit, la liste (ou backlog) de features est ordonnée. L'intérêt est de ne décomposer en stories que les features les plus prioritaires.

Sur quels critères s'appuyer pour ordonner les features ? Il existe de nombreuses techniques pour prioriser, qui reposent généralement sur la notion de valeur, mais aussi comme on peut le lire vers la fin de ce billet qui parle de Priority poker écrit en 2007 sur l'effort (que j'appelais à l'époque le coût, après j'ai utilisé un temps la taille).

Pour estimer l'effort, la pratique usuelle est de faire un Planning Poker. Mais il se fait plutôt avec des stories, donc une fois que le travail de décomposition des features (les plus prioritaires) en stories a été fait.

Alors ? On ordonne les features -et donc on décompose les premières- sans se préoccuper de leur effort, donc de leur coût ?

On peut effectivement s'en passer pour ne se préoccuper, dans un premier temps, que de la valeur (ou utilité) des features, sans tenir compte de l'effort ni donc du ROI.

On pourrait aussi, une fois qu'on dispose d'une liste de features et après avoir estimé leur valeur, pratiquer un planning poker à ce niveau-là pour estimer l'effort nécessaire pour les développer.

L'utilisation de la suite de Fibonacci pour estimer, de façon relative, l'effort des features non encore décomposées est possible, mais cela implique que l'unité sera le "point de feature", unité différente du "point de story" qui sera utilisé plus tard.

Dans le cas où on définit l'ordre des features sans avoir estimé leur effort, le Planning Poker qui était effectué pour planifier la release porte les stories décomposées à partir des features les plus prioritaires, suivies éventuellement des features non décomposées. On peut donc associer un effort à chaque feature, celui des plus prioritaires étant obtenu a posteriori avec la somme des efforts des stories associées. L'intérêt d'avoir un effort associé à une feature est d'aider à la planification, pour élaborer une roadmap.

Alors, estimer les features indépendamment pour mieux les ordonner, les estimer avec les stories pour mieux planifier ou bien ne pas les estimer du tout (pour éviter de perdre du temps) ?

Commentaires

1. Le mardi 17 avril 2012, 08:22 par Cédric

Je vois bien l'intérêt des features mais par contre je butte un peu sur celui de les évaluer avant de planifier. L'important me semble être la valeur. L'évaluation permet de planifier, de faire un burndown, mais pas à mon sens de prioriser.

Cédric

2. Le mardi 17 avril 2012, 10:26 par Geoffrey

Bonjour,

J'utilise régulièrement les features et c'est un objet indispensable pour nous afin d'avoir une vue à moyen/long terme du projet, même si cette vue est toute relative.
Estimer les features en avance permet de donner une estimation de la taille du projet et des périodes de livraison au management.

Par contre, j'ai une petite réticence à propos des « Features points ». Personnellement, je travaille avec une équipe débutante en Agilité et la notion de Story points est assez compliquée à assimilé pour éviter d’en rajouter une autre.
Donc pour résoudre cela, nous estimons encore plus relativement les user story composant cette feature. Au moment du planning du sprint on revoit notre estimation. De cette manière-là, nous manipulons toujours les mêmes objets avec les mêmes types de valeurs.