Scrum, temps passé en réunions et vélocité

Récemment, je discutais avec un client et il m’expliquait que depuis que l’équipe est passée à Scrum, le temps passé en réunions a augmenté et la vélocité a diminué. D’un autre côté, les équipes apprécient beaucoup le « backlog grooming » car cela leur permet de mieux comprendre le sens de leur travail ainsi que la vision du produit (à ce sujet n’hésitez pas à (re)lire l’article sur l’objectif de sprint).

Alors, doit-on s’inquiéter d’une perte de productivité lors d’un passage à Scrum? Passer à Scrum est-il forcément synonyme de « réunionite aigüe »?

les réunions dans Scrum

Scrum et le temps passé en réunion

Penser que l’on passe trop de temps en réunion est une notion subjective. Or, il est facile de mesurer le temps qu’une équipe scrum devrait passer en réunions en théorie, alors pourquoi rester sur une impression? Pour un sprint de 1 mois ça donne:

  • Sprint planning : 8h maxi
  • Revue de sprint : 4h maxi
  • Daily Scrum: 15mn maxi x20 jours = 5h
  • Rétrospective: 3h maxi
  • Backlog grooming: 10% de la capacité mais c’est peut être un peu trop. Disons 8h (2h/semaine).

Cela nous fait un total de 28h, soit 18.6% de la capacité. Il faut savoir qu’une moyenne de 20% du temps passé en réunions est courant en Scrum. Ces événements sont les seuls nécessaires pour que l’équipe soit en mesure de délivrer. Voici ce que vous pouvez faire pour optimiser cet aspect de votre activité:

  • Mesurer le temps réellement passé en réunions (le Scrummaster peut se charger de consolider)
  • Examiner en rétrospective les raisons possibles si cela prend plus de temps (laisser l’équipe s’améliorer). Ces événements sont limités dans le temps (time boxed), donc il est nécessaire d’aider l’équipe à respecter les durées maxi. Quelques raisons possibles de dépassement : 
    • On fait les réunions Scrum EN PLUS d’autres réunions traditionnelles (restes de waterfall, etc)
    • Des personnes sont à cheval sur plusieurs équipes (et donc multiplient les réunions)
    • Les réunions ne sont pas assez préparées à l’avance
    • Une culture d’entreprise propice aux réunions

La vélocité de l’équipe Scrum

La vélocité est un outil qui permet de mesurer la capacité d’une équipe à délivrer de la valeur dans le temps. Il arrive qu’il serve d’outil de mesure de productivité destiné au management (à tord ou pas, là n’est pas la question), mais cela peut être trompeur.

Il n’est pas rare qu’elle varie dans le temps: augmentation durant les premiers sprints, puis stagnation, voire diminution si le cycle de développement du produit passe par des défis techniques, ou de la dette technique à résorber.

Evitez aussi de comparer la vélocité entre équipes. Comme c’est basé sur des estimations en story points, chaque équipe a ses références et la valeur d’un SP n’est pas la même d’une équipe à une autre. Que mesurer en plus de la vélocité pour avoir une vision globale? Quelques exemples :

Ces indicateurs vont permettre de voir si la baisse de vélocité se fait en gagnant sur d’autres points (qualité, motivation etc), ou si elle est due à ces mêmes points qui se sont dégradés. Là encore, si problème il y a, ce sera à l’équipe d’aborder le point en rétrospective et à trouver une solution. Si elle y parvient, elle fera un pas de géant en termes de maturité, de cohésion et de solidarité.
Pour régler un problème en rétrospective, je conseille généralement ces 4 étapes :

  • Etat des lieux du problème (avec métriques)
  • Lister toutes les options possibles pour améliorer la situation (au moins 3)
  • En choisir une et la mettre en œuvre
  • Evaluer le résultat et adapter

Et vous? Avez-vous l’impression que le passage à Scrum a dégradé certains indicateurs de performance? Vous avez l’impression d’enchaîner les réunions? Votre productivité semble avoir baissé? Comment avez-vous géré la situation? N’hésitez pas à partager vos commentaires!

L’utilité réelle de l’objectif de sprint et comment le mettre en œuvre

Dans cet article, nous allons aborder l’importance de l’objectif de sprint, ses liens avec les cérémonies Scrum, comment le définir et comment l’utiliser.

sprint goal archery target

Pizzapido…

Arthur est Product Owner de Pizzapido, une application qui permet de commander une pizza fraîchement cuite pour la retirer dans un automate. Avec son équipe ils terminent le sprint 14 qui met un gros focus sur la redéfinition de l’expérience utilisateur de création de compte. En effet, il s’est rendu compte que certains utilisateurs ne parviennent pas au bout du processus de création de compte et que cela fait donc une perte potentielle de commandes et donc de revenus. Il a donc inclus dans le sprint 14 plusieurs User Stories pour améliorer cette partie de Pizzapido.

Continuer la lecture de « L’utilité réelle de l’objectif de sprint et comment le mettre en œuvre »