Qui estime les user-stories ?

estime les user stories
estime les user stories

Si au premier abord cette question peut amener à une réponse simple, elle ne le sera pas forcément : qui estime les user-stories ?

Vous pouvez également regarder la vidéo de La Minute Agile qui explique qui estime les user-stories :

La recommandation classique de qui estime les user-stories

De base, nous disons que seuls ceux qui ont des compétences de développeurs estiment les user-stories. Mais est-ce toujours suffisant ? Est-ce que cela couvre totalement la réalisation de nos user-stories ?

De base l’estimation consiste à estimer une user story de son état à « todo » à son état à « done ». Et dans les étapes intermédiaires, il y aura bien plus que la partie « développement » (dans le sens programmation) comme par exemple les tests, l’éventuelle documentation…

Le Product Owner ou/et le testeur estime ?

En product backlog refinement

En général je ne recommande pas l’estimation par ces acteurs sur les phases de backlog refinement. Par contre, dans certains contextes où les tests peuvent être complexes et sont fait par le product owner, je propose au product owner (ou testeur) de donner leur avis.

Il faut rappeler que les séances de refinement sont des séances de négociation, donc il est essentiel que tous les acteurs soient de vrais participants (et pas de simples observateurs).

En poker planning, je traduis ça par une carte « test is not easy » pour qu’ils rappellent aux membres ayant des compétences de développeurs qu’il ne faut pas sous-estimer la partie test. Ceux-ci pourront alors revoir leur estimation à la hausse pour s’accorder aux problématiques de tests soulevées. Parfois le développement d’une user-story pourra prendre quelques minutes alors que la partie test pourra être un vrai casse-tête chinois.

Cela peut être le cas aussi dans des cas de documentations ou d’autres thèmes.

Attention par contre au product owner qui force les estimations. J’ai déjà vu des product owner qui finissent par avoir le dernier mot ; parfois cela avec pour objectif de respecter des plannings prévus des mois à l’avance. Cela n’est plus dans le cadre de la négociation et doit être évité à tout prix.

En estimation de masse

Lors des estimations de masses pour avoir une vision d’un atterrissage avec le bucket system ou l’extreme quotation, il m’arrive de faire participer le product owner aux estimations. Il n’a pas le dernier mot mais quand son estimation est totalement différente avec l’équipe de réalisation, cela lui permet d’avoir des explications sur :

  • pourquoi c’est plus complexe que je l’imaginais
  • pourquoi c’est moins complexe que je l’imaginais

Cette façon de faire apporte un vrai partage entre les différents membres de l’équipe scrum.

Certains peuvent appliquer cette idée de faire participer le product owner aux estimations de refinement mais attention à ce que l’objectif de partage et de compréhension soit le seul à ses yeux.

Comment choisir qui estime ?

Selon les contextes, il est possible de faire estimer le product owner (voire le testeurs ou d’autres rôles). Cependant, il faut s’assurer que l’objectif de cette participation n’est pas pour de mauvaises raisons.

En général, le scrum master est un excellent observateur et saura déceler les éventuels problèmes d’une telle pratique ; il amènera l’équipe à mettre fin à ces pratiques si il décèle des objectifs qui ne vont pas dans le sens d’une équipe agile.

Pour les équipes non matures, pour simplifier, nous avons tendance à dire : « les développeurs estiment ». Ces équipes viendront elles mêmes à tester d’autres façons de faire sous les yeux de leur coach scrum.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.