Dans un standup Scrum, la discussion de ce qui a été fait hier devrait-elle être limitée aux tâches au tableau ou à tout le travail effectué?

Je sais que les règles Scrum dans les standups quotidiens disent que l'équipe ne devrait parler que de ce qu'elle a fait hier, de ce qu'elle fait aujourd'hui et de tout ce qui les bloque. Rien d'autre. Mais le problème est que, parfois, les développeurs passent leur journée à faire du travail sans rapport avec leurs tâches, puis en parlent dans le standup. C'est ce qu'ils ont fait hier!

D'après mon expérience, j'ai trouvé qu'il est plus efficace de parler des tâches au tableau, de garder le standup concentré et de garder l'attention de chacun sur ses tâches, de revoir ses estimations et de suivre ses dossiers quotidiennement.

Est-il valable de limiter la discussion aux tâches au tableau?

agile scrum meetings

— Shadin
source

Que les développeurs passent des journées entières à ne pas travailler sur leurs tâches pourrait être un problème qui serait invisible s'il n'était pas mentionné?

— RemcoGerlich

Tout le monde parle 30 secondes pour dire ce qu'il a fait avant. Dans quelle mesure voulez-vous plus ciblé? Vous ne passez pas en revue les estimations. Vous suivez les tâches lorsque vous les passez au gars suivant (réviseur ou testeur).

— gnasher729

Réponses:

Selon le contenu du Guide Scrum sur les standups quotidiens, les trois questions à discuter sont les suivantes:

Qu'est-ce que j'ai fait hier qui a aidé l'équipe de développement à atteindre l'objectif de sprint?

Que vais-je faire aujourd'hui pour aider l'équipe de développement à atteindre l'objectif de sprint?

Est-ce que je vois un obstacle qui m'empêche, moi ou l'équipe de développement, d'atteindre l'objectif de sprint?

Toutes les questions se concentrent sur l'objectif de sprint, pas sur les tâches au tableau. Encore une fois, selon le Scrum Guide, le Sprint Goal est créé dans Sprint Planning et définit «un objectif qui sera atteint au sein du Sprint grâce à la mise en œuvre du Product Backlog, et il fournit des conseils à l'équipe de développement sur les raisons pour lesquelles il construit le Incrément".

Tout ce que fait votre équipe de développement devrait, idéalement, aider l'équipe à progresser vers l'objectif de sprint. Il peut s'agir d'activités non planifiées qui ne figurent pas au tableau et qui doivent être effectuées, ou il peut s'agir de choses à un niveau inférieur qui peuvent avoir été prises en compte et estimées, mais à un niveau inférieur à un élément du tableau.

Je dirais que votre équipe parlera de tout ce qu'elle a fait hier. S'ils parlent de choses qui n'aident pas l'équipe à atteindre l'objectif de sprint, alors quelqu'un devrait en parler, surtout s'il y avait d'autres choses qu'ils auraient pu faire qui auraient rapproché l'équipe de la réalisation de l'objectif de sprint.

Une exception peut être si une personne prend en charge plusieurs équipes Scrum. Lors de la réunion, ils ne devraient probablement pas parler de tout ce qu'ils ont fait hier, mais de ce qu'ils ont fait pour soutenir l'équipe qui a actuellement le standup.

La rétrospective Sprint est le moment idéal pour discuter de ce problème avec l'équipe. Il y a beaucoup de questions à considérer:

L'équipe est-elle sous-travaillée sur les éléments liés à l'objectif de sprint?
Y a-t-il trop de travail imprévu?
D'où vient le travail imprévu et qui l'autorise?
Pourquoi les gens travaillent-ils sur des choses qui ne figurent pas au tableau?
Devrions-nous afficher plus de détails sur le tableau pour lier plus facilement ce que vous faites aux éléments du tableau?

— Thomas Owens
source

le problème avec "Sprint Goal" est son trop vague et wishywashy. dans la pratique Sprint Goal == terminer les tâches au tableau. si ce sur quoi vous avez travaillé n'est pas là, cela devrait être ou vous ne devriez pas y travailler

— Ewan

@Ewan Un client nous appelle et nous dit que le logiciel en direct est tombé en panne et que nous avons un journal et un rapport de bogue. Il est important de prendre le temps de trier ce rapport immédiatement, même s'il ne figure pas au tableau en ce moment. Cela peut être pris en compte ou mis dans l'arriéré, mais c'est quelque chose que j'ai fait hier et pourrait être la raison pour laquelle je n'ai pu aider Bob à résoudre son problème qu'après le déjeuner. Je ne devrais pas faire cette tâche à l'aveuglette, mais personne ne va probablement la mettre au tableau à moins qu'elle ne soit entraînée dans ce Sprint. Je peux aussi penser à d'autres exemples.

— Thomas Owens

vous devez ajouter un ticket "triage live bug" au tableau et le marquer comme terminé. Ensuite, à la fin du sprint, vous pouvez dire avec certitude. «Ce sprint, nous avons passé X heures à regarder les erreurs des utilisateurs. C'est pourquoi nous sommes en retard. nous devons mieux former le helpdesk 'Sinon, vous ne faites rien pendant ce sprint et le PM n'a que des excuses par ouï-dire de l'équipe' oh il y avait beaucoup de bugs à regarder cette semaine! haussement d' épaules

— Ewan

@Ewan Je pense que c'est incroyablement inutile. Je ne veux pas passer ma journée à écrire des billets. Un processus doit me permettre de faire mon travail, et prendre 90 minutes pour le triage au lieu de 95 minutes pour le triage, puis mettre un ticket qui dit que j'ai trié un ticket est idiot. Surtout si vous devez trier plusieurs tickets. Vous n'avez pas besoin de billets pour discuter des choses lors de la rétrospective. Si vous utilisez des outils électroniques, vous pouvez trouver des billets modifiés par l'équipe dans le Sprint pour voir s'il y avait beaucoup de choses à trier - pas de ouï-dire là-bas.

— Thomas Owens

le niveau de rapport si cela dépend de votre scrummaster / pm / entreprise. vous pouvez simplement rédiger un ticket "trigaing bugs" pour couvrir tout votre travail de la journée. Mais l'important est que vous l'enregistriez dans le cadre du sprint. ne présumez pas que sa juste prise en compte par une autre métrique

— Ewan

Non, tu devrais parler de ce que tu as fait hier.

Si ce n'est pas sur le tableau, vous devez effectuer l'une des opérations suivantes:

le mettre au tableau,
arrête de le faire
ou changer d'équipe.

La plus courante, par exemple pour les travaux d'urgence imprévus, consiste à rédiger une carte et à la coller sur le tableau. Cela garantit qu'à la fin du sprint, vous pouvez mesurer la vitesse et expliquer pourquoi les objectifs du sprint n'ont pas été atteints.

Un membre de l'équipe travaillant sur des choses qui ne sont pas dans le sprint est à mon avis l'une des principales raisons de l'échec des adoptions agiles. Le plus souvent, il s'agit d'un développeur détourné pour résoudre des problèmes en direct sur un autre projet.

Une autre chose ennuyeuse dans les sprints est "Le PM parle de réunions pour d'autres projets". À mon avis, le PM ne fait pas partie de l'équipe Scrum, il remplit le rôle Scrum «Product Owner» et est donc là pour répondre aux questions, pas pour signaler les progrès.

— Ewan
source

Il y a une chose telle que le travail non planifié - le travail qui doit être fait pour débloquer quelqu'un ou effectuer d'autres tâches qui sont sur le tableau, mais ce n'est pas sur le tableau. Souvent, il peut être plus rapide de le faire que de le mettre sur la carte. C'est à l'équipe de discuter de la façon de gérer cela. Mon équipe actuelle a des règles - tout ce qui est déployé dans un environnement de production ou d'assurance qualité ou des tâches qui prennent 2 heures sont intégrées au tableau. Il y a encore des tâches parfois plus courtes qui doivent être accomplies dont on parle, mais ne faites pas le tableau parce qu'il ne correspond pas aux critères.

— Thomas Owens

@Ewan, pouvez-vous développer cela? Qui gère la correction des bugs en direct, si ce n'est pas dans le Sprint? Comment le maître d'ouvrage peut-il être en même temps chef de projet? (Je veux dire qui est-il, ou jongle-t-il avec les deux rôles)

— Dennis

édité pour plus de clarté

— Ewan

@Dennis: Project Manager n'est pas un rôle Scrum.

— RemcoGerlich

@Ewan, merci. Ce n'est pas essentiel à la réponse, mais je suis curieux - le "PM parle de réunions pour d'autres projets", comment ça marche? Les PM entrent-ils en réunion sur le projet X, mais parlent-ils de Y? J'ai du mal à visualiser cela. Comment / pourquoi est-ce possible? Voulez-vous dire qu'ils entrent et commencent essentiellement à bavarder ou à devenir hors sujet ou y a-t-il une raison plus profonde pour eux de parler d'objectifs / besoins spécifiques à une réunion non immédiate? Je dirais "hé bien d'entendre ça mais je ne fais pas partie du projet Y ... aucune connaissance / expérience là-bas, pouvons-nous revenir à X?"

— Dennis