Je crois qu’on pars sur une incompréhension. Je ne challenge pas scrum ou l’agilité. Pas besoin de me ressortir les bouquins pour tenter de me convaincre, ce n’est pas du tout la question. Je pratique depuis pas mal de temps, et j’ai vu passer pas mal de façon d’aborder la chose.

Je réagis face à un billet particulier, d’un coach scrum que je sais expérimenté, qui visiblement met derrière la vélocité autre chose que moi. Quand je te lis je lis de la littérature mais pas du détail. L’effort tu mets quoi derrière ?

Pour reprendre le billet auquel je répondais : si derrière une US assez classique cette fois ci tu sais qu’il faut refactoriser en profondeur le logiciel, est-ce que tu reprends l’ancienne estimation (ce qu’il fait) ou est-ce que tu essayes plus de coller à une autre estimation voire en fait une nouvelle (c’est plus ainsi que moi j’aborde) ?

Quant à la vélocité, de mon expérience, passé les premiers temps et outre les cas exceptionnels et majeurs, elle est plutot continue justement. Pour moi c’est d’ailleurs un des seuls intérêts de l’exercice.
Chiffre à moyen et long terme en jour/homme avec une fourchette pas trop mauvaise, je t’assure que les chefs de projets expérimentés y arrivent très bien. Là où ça coince c’est ailleurs … et sur le détail. Je suis convaincu que l’utilisation des références passées faites par scrum aide à faire mieux, mais le gros bénéfice ne vient que quand on a une vélocité prédictible à court terme, et donc continue.