Si un devis n'est pas une promesse, en tant que propriétaire de produit, comment puis-je livrer mes projets sans savoir combien de temps cela prendra?
C'est l'un des plus grands malentendus concernant Scrum. La question de "Combien de temps prendra mon projet?" suppose que vous pouvez définir, à un moment donné, exactement ce que le projet impliquera pour terminer. Mais l'idée globale de Scrum est qu'elle reconnaît que les choses que vous apprenez sur un projet, pendant que vous travaillez sur le projet, vont changer la définition du projet.
La façon la plus courante de définir un projet est de lister les fonctionnalités qu'il aura. En règle générale, un projet est terminé lorsque toutes les fonctionnalités ont été implémentées. Mais que se passe-t-il si, lorsque vous travaillez sur un projet, vous réalisez que 5 des fonctionnalités identifiées au début ne seront pas nécessaires, mais il y a 7 fonctionnalités auxquelles les gens ont pensé au cours des 6 premiers mois qui devraient vraiment être incluses? Qu'est-ce que cela fait à la question du temps que cela prendra?
Un autre facteur est que les choses que vous apprendrez changeront votre compréhension de la façon d'implémenter certaines fonctionnalités, et à mesure que vous vous rapprocherez de la mise en œuvre de chaque fonctionnalité, vos estimations vont changer. Personnellement, je m'abstiendrais de mettre des estimations numériques sur tout ce qui n'approche pas de l'horizon de mise en œuvre - peut-être en utilisant des estimations descriptives comme "minuscule", "petit", "moyen", "grand" et "énorme" ou "épique". Ensuite, vous n'impliquez pas une précision supérieure à ce que vous êtes capable d'estimer.
À vrai dire, "Combien de temps cela prendra-t-il?", N'est pas plus responsable que, "Que sera-ce quand ce sera fait?". Les comptables et les hommes d'affaires traditionnels détestent cela, c'est pourquoi il est très difficile de s'éloigner de Waterfall dans certaines organisations.
C'est aussi pourquoi vous devez prendre beaucoup de discussions sur la vitesse et les mesures avec un grain de sel. Les projets logiciels ont une sorte de principe d'incertitude de Heisenberg intégré, et si vous passez trop de temps à affiner les mesures, vous allez juste vous retrouver avec un non-sens extrêmement précis.
Alors non, une estimation n'est pas une promesse. C'est une estimation. La "promesse" est l'engagement de l'équipe à terminer un certain nombre de fonctionnalités ou d'histoires dans un sprint particulier.
Les estimations doivent être juste assez précises pour permettre à l'équipe d'identifier combien de fonctionnalités (ou d'histoires) elles peuvent intégrer parfaitement dans un Sprint. La cohérence est encore plus importante que l'exactitude des estimations, car l'équipe apprendra combien de travail les estimations peuvent contenir dans un sprint, même si le travail réel s'avère généralement deux fois plus important que prévu. Tant qu'il est éteint, ils pourront planifier.