Finir une story c’est bien, finir une feature c’est mieux

Arrêter de commencer, commencer à finir. Mais pas seulement.

Il y a quelque temps, j'avais audité un projet dont le tableau de features, s’il avait été fait[1], aurait ressemblé à peu près à ça :

Features en cours et pas finies

Tout un tas de features commencées, aucune de finie, même après des mois de sprints.

Avec cette vue, on voit bien que l’avancement peut être résumé très vite. Zéro. Rien de fini. Pas besoin de feuille de calcul.

Pourtant sur le projet, l’avancement n’était pas présenté comme ça : il y avait des stories de finies, une vélocité obtenue à chaque sprint. Des mesures sur des éléments pas véritablement significatifs, puisqu’il y avait un engagement non pas sur des stories, ni seulement sur des points, mais sur une liste de features.

On m’avait donné de bonnes raisons pour expliquer cette situation : la plus impactante était qu’il fallait impliquer toutes les parties prenantes expertes d’un domaine (donc de features). On leur montrait donc que des choses se faisaient pour eux en commençant les features qui les intéressaient.

Arrêtez de commencer, commencez à finir vos features, leur ai-je dit.

Pour arrêter de commencer, il faut une stratégie pour définir la priorité entre les features (dans le schéma ci-dessus, elles sont en vrac[2]).

Pour finir plus vite une feature, il y a 2 façons :

  • en commencer moins en même temps. La pratique courante qui vient Kanban est de donner une limite explicite (le WIP ou TAF).
  • la réduire, c’est à dire retirer des choses (des stories) pour ne garder que l’essentiel. C’est tout l’art de l’affinage, à pratiquer sur les stories pour découper dans la feature.

Pour ce qui est du suivi de l’avancement, je recommande vivement de le faire sur les features plutôt que sur les stories. Et donc en se passant des estimations en points sur les stories.

Comment ? C’est ce que nous verrons une prochaine fois.

Notes

[1] Il y avait à la place un gros tableau excel avec des calculs précis (mais faux) d'avancement donnant des % de finition par feature.

[2] Dans le contexte d'une organisation qui a l'habitude de la spécification monolithique, c’était un changement de culture et le Product Owner n'avait le pouvoir suffisant pour le porter.