Comment dois-je réagir lorsque peu de stories sont intégrées durant un sprint ?

Durant plusieurs rétrospectives, l’équipe remonte le fait que peu de stories sont intégrées. Ce qui pose question, vu que les membres ne se sont jamais retrouvés sans tâches.

Après analyse des burndowns des différentes itérations, il en ressort donc effectivement que l’équipe a une bonne productivité mais que les stories ne sont pas intégrées essentiellement pour les raisons suivantes :

  • Elles sont toujours en cours de revue
  • Elles n’ont pas encore commencé
  • Elles sont en attente de personnes extérieures à l’équipe

Scrum-AaarghEmergency

Cas des stories en revue :

Il est un principe qu’il faut avoir en tête en permanence : le cycle de vie d’une story doit être le plus court possible, car l’objectif d’une itération est de délivrer un maximum de valeur. Cela a aussi l’avantage pour le développeur qui a des retours à traiter d’être plus en mesure de se souvenir de ce qu’il a fait.

Si on se penche sur ce point, on constate que les causes identifiées contreviennent au principe précédemment cité. En effet, on constate que le délai entre le passage en revue et le moment où le développeur fait sa revue est très long. Il peut s’écouler plusieurs jours.

En continuant ainsi, on s’expose à une situation plus compliquée à gérer et une frustration de l’équipe de voir des revues s’amonceler en continue.

Une des solutions à adopter est de débloquer justement toutes ces stories en revue pour les faire passer à une autre étape du cycle. Comment ? En demandant à tout le monde de s’arrêter de développer quelques heures et de traiter toutes ses revues.

Ainsi, chaque story peut reprendre son cycle de vie.

Pour éviter aussi d’agir ainsi à chaque fois, il peut être intéressant de mettre en place une durée max de prise en compte de la revue (ex :  24h). Pour aider à faire respecter ce principe, la règle serait que tout le monde traite ses revues en même temps au moment de coupures dans la journée. Par exemple, en arrivant le matin, chaque développeur remonte les revues qu’il a à traiter au Daily Scrum Meeting.

Ainsi, tous les développeurs se synchronisent sur les revues qu’ils ont à faire et cela permet de prévenir les autres afin qu’ils suivent l’avancée de leur story et ainsi avoir une idée de ce qui les attend par la suite.

Cas des stories non commencées :

Cela veut dire que les capacités de traitement de l’équipe ont été surestimées par rapport à ce qui a été planifié. Cela peut venir d’une estimation erronée, d’une vélocité incorrecte. Dans ce cas, il est nécessaire de faire une ré-estimation des tâches en fin de sprint pour que l’équipe s’améliore dans les estimations. La vélocité peut également être réajustée.

Cas des stories en attente :

Pour ce dernier cas de figure, le développeur a peu de moyens à sa disposition pour agir car les stories sont en attente de retours de personnes externes à l’équipe. Par exemple, ce peut-être un architecte qui est pris sur d’autres sujets et qui ne peut faire un retour sur l’architecture ou le fait qu’une autre équipe ait terminé un de ces développements pour avancer. C’est le rôle du LT de demander à ces intervenants extérieurs de lui fournir une date de retour ce qui facilitera la planification de ces stories.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s