Le coût et le prix

Quand l’équipe estime en temps idéal des développements, elle estimela complexité de construction, bref le coût de production.

Implicitement ou explicitement, le product owner estimera lui en points, quelque chose qu’il lie confusément au service rendu, aux tâches simplifiées, aux économies futures dues à un surcroit de productivité ou au gain de compétitivité avec des fonctionnalités nouvelles. Il pense s’appuyer aussi sur une vision de la complexité de réalisation, mais celle-ci est approximative. Il pense avoir une vision du coût, mais finalement ce qui compte c’est l’analyse de la valeur perçue, bref du prix qu’il est prêt à payer.

Dans tous les cas, il y a un mismatch entre le prix accordé à une user story (ce que je veux bien payer, basé sur ce qu’elle m’apporte) et son coût (ce qu’il faut payer pour l’obtenir). Sans parler des cas où le product owner prétend chiffrer lui même la complexité.

Cela vaut aussi pour la priorité : priorité demandée par le product owner (fonctionnalités dont j’ai besoin opérationnellement), priorité de réalisation (contraintes, fonctionnalités dont j’ai besoin pour tester, pour des économies d’échelle).

Pour les priorités, la réconciliation est relativement simple : le product owner fixe les grandes lignes, l’équipe s’organise dans ce cadre en déplaçant les user story d’une itération à l’autre mais en respectant la priorité des release.

Ca ce gâte quand on discute lotissement en releases, en introduisant les estimations. Le débat est plus compliqué, passionnel.

Il faut intégrer d’autres facteurs, comme la confiance (initiale, puis méritée) qu’à le product owner dans la capacité de l’équipe à avancer, dans la bonne fois de la DSI. Elle s’appuie bien sûr sur l’historique.

Il y a aussi la maîtrise de la « dette technique » de façon à ne pas mettre en danger la productivité future pour des gains à court terme.