Alors par contre je viens de tiquer.
Déjà, ça vaut le coût, je pense, de rappeler que Scrum ne prévoit pas d’estimation ni de calcul de vélocité : ces termes n’apparaissent pas dans le guide.
La vélocité ce n’est pas la quantité de travail effectué (= consommé) mais la valeur ajoutée (= produit) par le sprint divisé par le temps pour comparer des sprints de durée différente. Elle se mesure par la somme de points de valeur associé aux US terminées pendant le sprint. Comparer la vélocité d’un sprint à l’autre permet d’identifier certains problèmes comme la désorganisation de l’équipe, le choix de story à faible valeur ajoutée, ou le fait d’avoir attaqué un développement plus complexe que ce qu’on avait prévu au départ. Ce n’est pas un indicateur de performance car des explications autres peuvent expliquer les fluctuations.
La consommation, elle, se mesure au niveau du sprint sans descendre au niveau des US. On peut le faire sans fliquer l’équipe par un simple calcul: Nb ETP x CJM x durée du sprint. Et là, il faut bien tenir compte du temps passé par la testeuse, car j’imagine qu’elle doit bien imputer sur le projet. Sinon elle ne serait pas payée. Comparer la valeur produite et le consommé du sprint permet de mesurer un ROI pour démontrer la rentabilité de l’équipe. On a claqué 30k€ dans un sprint, si ça rapport 8k€/semaine c’est vite rentabilisé. Si on a passé 90 k€ dans un sprint pour rapporter 1k€/an, vous allez vite vous ruiner.
Le loi de Conway c’est l’idée que si l’organisation de l’équipe n’est pas alignée sur l’architecture technique, alors tu vas galérer jusqu’à adopter une architecture technique alignée sur la structure organisationnelle (et c’est toujours la structure organisationnelle qui gagne).
J’en parle un peu plus dans ce sujet de discussion :