Estimation d'un pic d'activité de recherche
Comment évaluer un « spike » de recherche : un « spike » est un intervalle de temps défini avec un livrable, et non une « story ». Comment éviter qu’il ne devienne insidieusement le travail dont il était censé délimiter le périmètre.
Une hausse ponctuelle n’est pas un événement. Ne la traitez pas comme tel.
Les « spikes » sont des périodes de travail délimitées assorties de livrables — « passez deux jours là-dessus, revenez avec une recommandation ». Le chiffre indiqué sur la fiche correspond à un budget, et non à une prévision. Estimer un spike à l’aide du « feature deck » n’est pas la bonne méthode : vous ne savez pas ce que vous allez découvrir, la question de l’effort relatif ne s’applique pas, et l’équipe finira par se disputer au sujet d’un chiffre qui ne représente rien.
L’autre risque est de laisser le « spike » accaparer le travail. L’équipe attribue une note de 3, le « spike » dure deux semaines, rien n’est livré et l’histoire d’utilisateur initiale n’est toujours pas estimée. Un « spike » comporte un délai et un livrable. Si ces deux éléments ne figurent pas sur le ticket, vous n’estimez pas un « spike » : vous approuvez une étude à durée indéterminée.
Ce qui se dit dans la salle
Ingénieur : « Je ne sais vraiment pas de quoi il s’agit tant que je n’ai pas regardé. »
PM : « À quoi cela ressemble-t-il, une fois « terminé » ? Un document ? Une démo ? »
Introduction : « Dans deux jours, nous réévaluerons la situation à la lumière de ce que vous aurez découvert. »
Question : « Que se passe-t-il si le pic indique “ne le construisez pas” ? »
Questions qu’il convient de se poser avant de voter
- Quelle est la durée prévue : une demi-journée, deux jours, une semaine ?
- Quel est le résultat attendu : un document, un prototype, une recommandation, une mesure ?
- Qui évalue les résultats, et selon quels critères ?
- Que se passe-t-il si la réponse est « ne pas compiler cela » ?
- Cela s’inscrit-il dans le rythme de l’équipe ou en dehors du cycle ?
Certaines équipes excluent totalement les pics de vitesse de leurs chiffres : il s’agit d’investissements, et non de livraisons, et confondre les deux fausse le signal de planification. Les deux approches sont valables ; en revanche, ne pas en choisir une et ne pas l’appliquer de manière cohérente ne l’est pas.
Votez un budget assorti d’un délai et d’un résultat attendu, puis réévaluez la situation réelle par la suite.
À lire également : les techniques d’estimation pour les tâches plus floues, et les erreurs courantes au Planning Poker concernant l’intrusion de l’exploration dans le story. Parcourez les autres exemples d’estimation concrets, ou lancez une session gratuite de Planning Poker après le spike, et non pendant.