Le dernier sprint d'une release

En quoi le dernier sprint d'une release est différent des autres ?

L'Agilitateur revient dans "que fait-on dans la dernière itération ?" sur le statut particulier de la dernière itération d'une release. Se garder pour la fin un sprint de "stabilisation" (ou durcissement) n'est effectivement pas une bonne idée. Mike Cohn me le confirme dans un récent message :

I stopped using the term "stabilization sprint" and now use "release sprint." To have a stabilization sprint implies that the software can be unstable at some point and that's a bad idea.

C'est donc la version officielle de Scrum, reprise par Ken Schwaber, d'avoir un release sprint. Les tâches effectuées pendant ce sprint dépendent fortement du type de déploiement du logiciel (mise en production à chaud, packaging du produit, mise à disposition par téléchargement en ligne...)
Nous venons de vivre le dernier sprint d'une release pour le projet IceScrum. Voici quelques conseils tirés de cette expérience :

  • penser au déploiement et à ce qu'il implique suffisamment tôt pour décider si le travail peut être reporté à la fin ou doit être fait avant
  • mettre dans le backlog des items non fonctionnels liés au déploiement, aux performances, aux environnements cibles et les estimer pour les prendre en compte dans la planification de la release, ce qui évitera de devoir ajouter un sprint au dernier moment
  • essayer de ne pas trop modifier de code lors du dernier sprint, c'est trop tard
  • du point de vue gestion, considérer ce sprint comme les autres (même durée, planification selon vélocité, des scrums quotidiens, revue...)