Les négociations et les tentatives de réduction des estimations Scrum sont-elles des éléments légitimes du processus?

J'ai remarqué lors de réunions Scrum que les développeurs donnent souvent des estimations réalistes sur les histoires. Cependant, même des histoires assez simples nécessitent beaucoup d'efforts pour la configuration, la mise en place de composants tiers, les tests et la construction finale, et le système a accumulé une certaine dette technique, de sorte que les estimations semblent souvent trop élevées pour le propriétaire ou la direction du produit.

Le bon de commande essaie fréquemment de battre de telles estimations, comme: "Quoi, vous voulez 13 points d'histoire [4 jours] pour cette histoire, cela ne peut pas être! Je ne peux pas l'expliquer à la direction, quelqu'un devrait être capable de coder cela avec 3 SP [en 4 heures]! ". En conséquence, les développeurs se tordent les bras pour s'engager sur une estimation de 5 ou 8 points d'histoire [1,5 à 2 jours] (les estimations Scrum sont toujours considérées comme des engagements, pas seulement des prévisions).

Bien sûr, sans aucun plan pour réduire les attentes (principalement sur les tests et la qualité), ces sprints échouent fréquemment. L'estimation des développeurs est honnête et réaliste, et le fait de battre l'estimation ne réduit pas le travail réel à effectuer.

On peut dire: "Vous ne devriez pas prendre un engagement impossible, juste parce que quelqu'un vous pousse à le faire!" Mais à mon avis, le travail d'un développeur est de concevoir et de coder des logiciels, pas de négocier ou de résister à la pression! Il peut y avoir des prises de tous les métiers, généralement ceux traitant directement avec des clients externes, mais ce n'est pas la majorité des développeurs de bureaux!

Pour moi, cette pratique fait simplement ressembler les programmeurs à des saccades, provoque des échecs de sprint constants et empêche des estimations réalistes, ainsi que la recherche d'améliorations réelles.

Que disent les directives Scrum à ce sujet, ou disent-elles quelque chose à ce sujet?

EDIT: temps remplacé par des points d'histoire. Je faisais référence à la phase d'estimation initiale avec Planning Poker et les points d'histoire, pas à la planification détaillée des tâches. Je viens de mettre les jours / heures là-bas, parce que c'était un dialogue typique comme ça parfois, aussi avec du temps au lieu de points. Désolé pour toute confusion! Les exemples de points d'histoire représentent des périodes plus longues que les exemples de temps.

EDIT 2 Il n'y a actuellement pas de Scrum Master dédié, et le PO joue ce rôle quand il s'agit de réunions d'estimation. C'est donc probablement le conflit de rôles qui aggrave cette négociation inappropriée, car il apparaît comme une autorité, au lieu d'un scrum master neutre ou développeur. Peut-être, cela peut être corrigé en le prenant comme un participant biaisé au lieu d'un "maître", tant qu'il n'y en a pas.

La situation que vous décrivez est toxique. Ce type de négociation ignore la réalité et l'expertise de l'équipe, il masque volontairement les informations de l'équipe et de l'organisation dans son ensemble, et il empêche l'équipe de s'améliorer avec le temps.

Si vous voulez cité http://www.scrumguides.org/scrum-guide.html en tant qu'autorité, je voudrais souligner:

Seule l'équipe de développement peut évaluer ce qu'elle peut accomplir au cours du prochain sprint.

et

Scrum mise sur la transparence. Les décisions d'optimiser la valeur et de contrôler les risques sont prises en fonction de l'état perçu des artefacts. Dans la mesure où la transparence est totale, ces décisions ont une base solide. Dans la mesure où les artefacts ne sont pas totalement transparents, ces décisions peuvent être erronées, la valeur peut diminuer et le risque peut augmenter.

Le propriétaire de votre produit peut souhaiter qu'une tâche soit possible en seulement 4 heures. Cela pourrait même être un objectif raisonnable. Une réaction saine pourrait être d'accepter l'estimation de l'équipe, de la mesurer si elle est exacte et de demander "que faudrait-il changer pour pouvoir accomplir ce genre de tâche plus rapidement?" Négocier la portée du travail impliqué dans la tâche peut également être raisonnable et souligner une différence importante dans la façon dont les développeurs et le propriétaire du produit comprennent ce travail à portée de main. Exiger que l'équipe modifie ses estimations sans nouvelles informations ne garantit que des estimations inexactes.

L'équipe de développement peut utiliser de nombreuses stratégies pour essayer de changer ce modèle, mais lorsque vous donnez un exemple de réponse «Je ne peux pas expliquer cela à la direction», je suis très nerveux. Il semble que votre propriétaire de produit n'ait pas la confiance de la direction (les estimations inexactes qu'il produit n'aident probablement pas) et peut ne pas vouloir être transparent sur les défaillances actuelles du processus.

À mon avis, l'une des plus grandes réalisations de SCRUM est le développement de points d'histoire, avec l'intention explicite exprimée d'éviter les problèmes de négociation mentionnés ici. L'intérêt des récits est d'éviter un lien direct entre une tâche et le nombre de jours qu'elle prendra. Au lieu de cela, ces deux concepts sont liés par l'idée de vitesse.

Si j'étais un développeur, et que je me faisais tordre le bras pour appeler une histoire de 13 points une histoire de 8 points, je serais heureux d'obliger. Ce sont leurs capacités d'estimation qu'ils ont un impact. Je vais simplement mettre à l'échelle toutes mes difficultés pour qu'elles correspondent. Finalement, la vitesse de l'équipe diminuera en termes de points d'histoire par semaine pour correspondre à la volonté de la direction de "distribuer" des points d'histoire. Les chiffres fournis à la direction doivent correspondre: «Nous avons réussi à réduire le nombre de points de travail nécessaires pour atteindre le jalon de 50%. Cependant, nous avons constaté une diminution correspondante de la vitesse de 50%, donc l'effet net est que nous vont accomplir exactement ce que nous allions accomplir dans exactement le temps que cela allait prendre. " Le concept de vitesse existe pour combattre les vœux pieux de la haute direction.

Il y a maintenant deux extrêmes qui, je pense, méritent d'être examinés. L'une est un échec complet de la direction et l'autre est en fait une préoccupation très valable pour la direction. Le premier cas est une condamnation à mort pour SCRUM, lorsque les développeurs sont informés "que vous n'êtes pas assez productif. Vous devez produire plus de points d'histoire de travail." Si cela se produit, vous n'utilisez pas réellement SCRUM, vous êtes un Cookoo, qui a expulsé SCRUM du nid et essaie d'être nourri par la mère oiseau qui revient au suivant.

Maintenant, il y a un cas où je pense que la direction devraitêtre capable de s'engager dans la torsion du bras comme ça. Il devrait être raisonnable pour le client de dire "Je ne peux pas me permettre 50 points d'histoire pour terminer cette tâche si votre vitesse est de 20 points / semaine. J'ai besoin que vous l'accomplissiez en 30 points d'histoire", si ce client le souhaite de renégocier le contenu de ces histoires pour réduire leur portée de 40%. SCRUM n'est pas un ticket de repas gratuit pour les développeurs de faire ce qu'ils veulent, c'est un outil de communication pour les aider et la direction discuter ouvertement de ce qui doit être fait. Il est également valable pour un client de mettre la pression sur le développeur et de dire "faire la tâche en 30 points" s'il est disposé à accepter le risque inhérent que le travail ne soit tout simplement pas terminé à temps. Lorsque le délai est dépassé, si les développeurs peuvent dire " puis acceptez tout ce qui a été fait. Je pense qu'il existe de meilleures façons de mesurer la productivité d'une équipe, mais je dois admettre que c'est un processus qui fonctionne. puis acceptez tout ce qui a été fait. Je pense qu'il existe de meilleures façons de mesurer la productivité d'une équipe, mais je dois admettre que c'est un processus qui fonctionne.

D'une part, le bon de commande ne devrait pas donner des informations sur les tâches à la direction. Les estimations de tâches sont strictement à l'avantage de l'équipe. La seule chose que quiconque en dehors de l'équipe doit savoir, c'est sur quelles histoires ils travaillent, quelles sont leurs valeurs en points et quelle est la vitesse moyenne de l'équipe. T

Deuxièmement, à moins que l'OP ne soit un développeur de niveau supérieur ayant une connaissance approfondie du logiciel, son opinion sur les estimations de tâches ne devrait pas avoir beaucoup de poids. Les développeurs sont ceux qui connaissent le système et ceux qui font le travail. À moins qu'ils soient tous fraîchement sortis de l'école avec des compétences d'estimation nulles, leurs estimations doivent être exclues.

Cela ne veut pas dire que les estimations ne peuvent pas parfois être remises en question. Si tel est le cas, cela doit se produire de manière positive. Par exemple "avez-vous considéré que nous avons déjà fait la moitié du travail pour" x "", ou "vous êtes-vous souvenu d'inclure du temps pour faire Y?".

Conclusion: les développeurs doivent se sentir en sécurité pour faire toutes les estimations qu'ils souhaitent, tant qu'ils tentent de bonne foi d'être précis. S'ils disent que quelque chose prend quatre heures, vous devez l'accepter.

Que disent les directives Scrum à ce sujet, ou disent-elles quelque chose à ce sujet?

Ils ne disent rien du tout. L'estimation des tâches ne fait pas partie de la mêlée. Avec Scrum, l'estimation s'arrête aux points de l'histoire. L'estimation des tâches est simplement un outil pour aider les équipes à mieux évaluer les points d'histoire en s'assurant d'avoir réfléchi à tout le travail nécessaire pour terminer une histoire.

C'est la tâche du Scum Master de s'assurer que le processus de mêlée est suivi. Cela implique de s'assurer que l'équipe ne s'engage pas (systématiquement) sur la quantité de travail qu'elle peut effectuer dans un sprint.
D'une part, cela signifie régner sur une équipe trop enthousiaste, mais d'autre part aussi repousser le Product Owner s'il fait pression sur l'équipe.

Une bonne façon de garder l'engagement / la prévision réaliste est de regarder les histoires qui se sont réellement réalisées au cours des derniers sprints. C'est ce que l'équipe a prouvé qu'elle peut accomplir, il est donc inutile de consacrer beaucoup plus de travail à un sprint, car cela ne sera pas terminé.

Comme d'autres réponses l'indiquent également, la négociation des estimations données par l'équipe ne fait pas partie du processus Scrum. L'équipe est la plus familière avec le logiciel, elle doit donc connaître le mieux le travail de quelque chose.

Ce qui peut être négocié, c'est la portée d'une histoire. Si le chef de produit pense qu'une histoire est estimée comme étant beaucoup plus grande ou plus petite que ce à quoi il pouvait raisonnablement s'attendre, il peut demander une clarification à l'équipe pour voir si la vue du travail qui doit être fait correspond aux parties.
Si l'histoire représente vraiment beaucoup de travail, le Product Owner peut décider de la diviser en plusieurs histoires plus petites et de distribuer la fonctionnalité sur ces histoires plus petites.

L'équipe est responsable de fournir la qualité et cela ne devrait jamais être ouvert à la négociation.

Oui et non.

Oui, l'équipe de sprint devrait négocier avec le propriétaire du produit sur ce qui entre dans le sprint.

Non, le propriétaire du produit n'a pas son mot à dire sur la durée des choses. Vous êtes les experts, pas eux.

Écoutez, vous ne devriez pas avoir à faire face à ce genre de déchets - votre manager ou chef d'équipe est là pour vous préparer au succès. Cela signifie avoir affaire avec le PM (ou son patron) afin que vous réussissiez. Cela dit, ce n'est pas si difficile.

"Non."

Que vont-ils faire? Écrire le code lui-même?

Autoriser ce comportement est un échec du Scrum Master. Son travail consiste avant tout à protéger l'équipe. L'OP, pour les raisons décrites ci-dessus, est à courte vue. Le Scrum Master devrait intervenir et, d'une manière positive, recadrer le contexte de la discussion.

Une telle pression entraînera bien sûr une pression à la baisse sur la vitesse, ce que l'OP a déjà cité. Si les équipes ne terminent pas systématiquement leurs sprints, le Scrum Master devrait à nouveau intervenir et demander pourquoi cela pourrait être le cas. Dans des environnements vraiment toxiques, les membres de l'équipe peuvent ne pas se sentir libres d'être honnêtes dans les rétrospectives. Mais dans cette situation, le Scrum Master a la responsabilité de dénoncer les mauvais comportements et de protéger l'équipe.

Si vous vous trouvez dans une situation dans laquelle votre Scrum Master ne peut pas ou ne veut pas faire ces choses, alors vous avez probablement besoin d'un Scrum Master différent. L'OP répond à des pressions typiques. L'équipe, en spéléologie, répond également comme le font souvent les humains. C'est le travail du Scrum Master de voir ce que c'est et d'y mettre un terme. La responsabilité du PO ici est d'en parler dans la Rétrospective et, si nécessaire, auprès des responsables et des managers. Si cela ne résout toujours pas le problème, mettez à jour votre profil LinkedIn et trouvez de meilleures personnes avec qui travailler.

Une équipe de développement de produits (c'est-à-dire tout le monde, du propriétaire du produit aux développeurs en passant par les testeurs) peut suivre le processus agile et obtenir de bons résultats avec des personnes raisonnablement compétentes et des attentes réalistes.

Ou ils peuvent suivre un processus qui ressemble superficiellement au processus agile.

Ce PO pense probablement qu'il obtiendra de meilleurs résultats en essayant d'obtenir des estimations de temps plus faibles pour les tâches. Bien sûr, cela ne fonctionne pas. Si quelque chose prend trois jours, vous me donnez beaucoup d'argent et je donnerai une estimation que je peux faire en une heure. Cela prendra encore trois jours. Si vous venez me crier dessus parce que ce n'est pas fini dans une heure, comme promis, cela prendra cinq jours.

Tout ce qu'il obtient, c'est briser le processus agile et renoncer à tous les résultats positifs qu'il pourrait obtenir. Le Scrum Master doit avoir l'expérience, le pouvoir et le courage de l'empêcher. Si la direction fait quelqu'un de Scrum Master qui n'a pas l'expérience, ou ne donne pas au Scrum Master le pouvoir d'empêcher cela, c'est leur faute si Agile se casse. Si le scrum master n'a pas le courage, alors il partage le blâme avec le PM.

Je dirais que cela dépend beaucoup de la motivation ici. L'objectif primordial de l'estimation est de se faire une idée de ce que l'équipe peut accomplir au cours d'un sprint donné, ce qui permet ensuite de prévoir les travaux futurs en fonction de cette vitesse. Par exemple, si l'équipe termine 30 points d'histoire à chaque sprint et qu'il y a environ 60 points d'histoire devant l'article X dans le carnet de commandes, le responsable du produit peut alors raisonnablement dire que l'article X sera terminé en quelque chose comme 6 semaines (sur la base d'un sprint standard de deux semaines).

Pour rendre cette estimation aussi précise que possible, il n'est pas rare d'avoir un désaccord sur le nombre de points d'histoire d'un élément particulier. Scrum l'encourage réellement. Ce désaccord peut parfois même être chauffé. Cependant, l'objectif final ultime doit être d'estimer avec précision la complexité de l'IBP, et non de dégonfler artificiellement l'effort afin que vous puissiez essayer d'enchaîner plus d'IBP à une vitesse donnée.

C'est en fait ainsi que la planification du poker fonctionne, en principe. Chacun expose son estimation. Le Scrum Master prend ensuite l'estimation haute et basse et demande pourquoi le membre de l'équipe pense que cela devrait être aussi haut / bas. Cela donne à l'équipe une chance d'entendre des perspectives alternatives sur le travail impliqué et d'avoir une meilleure idée de la complexité de la tâche. Après discussion, chacun jette à nouveau ses estimations. Ce processus est rincé et répété jusqu'à ce qu'il y ait un consensus général sur la complexité.

En d'autres termes, il n'est pas faux de remettre en question votre estimation, étant donné que le challenger a une raison pour laquelle il n'est pas d'accord, à part qu'il veut juste qu'il soit plus bas. Il est donc de votre responsabilité de convaincre votre équipe que votre estimation est correcte, si vous pensez qu'elle l'est toujours.