Sprints à vélocité réduite

Cette semaine, j'avais 2 revues de sprint

Cette semaine, j'avais 2 revues de sprint, mardi pour la fin du sprint 3 chez mon client à Paris et hier pour le sprint 2 de la release de mars sur le projet IceScrum.

Des revues de sprint basées sur des démonstrations, effectuées les 2 fois en présence de personnes extérieures à l'équipe très intéressées par le produit. Parmi ces personnes, des utilisateurs ou futurs utilisateurs, ce qui a permis d'avoir de nombreuses questions sur les fonctionnalités montrées.

Bref, des réunions très positives sur l'aspect feedback. Cependant, dans les deux cas, la vélocité mesurée a été plutôt basse et en deçà de la vélocité prévue.

En effet, des user stories présentées n'ont pas été -logiquement- considérées comme finies.

Dans le premier cas, elles n'ont pas été considérées comme finies parce que le Product Owner ne les avait pas testées auparavant. Il n'avait pas eu les moyens de le faire parce que la version a été produite au dernier moment juste avant la démo.

Dans le second cas, le manque de tests suffisants était un peu plus flagrant : la démo a montré des plantages intempestifs et des régressions. Ce sont les signes d'une erreur connue pour une revue de sprint : l'équipe modifie le code au dernier moment et présente une version mal testée.

A condition de bien mener une rétrospective après (ce qui a été le cas), la déception -compréhensible- de l'équipe d'avoir une vélocité réduite par rapport aux prévisions n'est pas un gros problème dans le suivi de Scrum par rapport au feedback apporté par la revue.