Une release est une série de sprints successifs. C'est une période de temps. Comment et quand déterminer la fin de la série et donc la fin de la release ?

Il y a la façon adaptative : la fin de la release n'est pas fixée, elle est envisagée à la fin de chaque sprint. On parle de release ajustable.

Il y a la façon prédictive : la date de fin de la release est décidée, c'est ce qu'on appelle une release à date fixée. Cela comporte des avantages.

Une release ajustable peut devenir à date fixée pendant son déroulement. A la fin d'un sprint, on décide avec le product owner que le produit est dans un état qui permet dé définir à quelle date on pourra finir la release.

On peut évoquer un troisième type de release, même s'il n'est pas agile, c'est la release à périmètre fixé (dans la pratique, le périmètre n'est jamais fixe). Le périmètre est défini par les éléments du backlog à faire.

A quoi sert de connaître le type de release ? Cela est déjà une information publiée, importante pour l'équipe et à l'extérieur. Cela permet également de faire une planification :

  • pour une release à périmètre fixé, l'objectif de la planification est de calculer la date de fin.
  • pour une release à date fixée, l'objectif de la planification est de calculer les fonctionnalités (stories) qui seront finies à cette date.

IceScrum permet déjà une planification automatique en associant des éléments du backlog sur les sprints en fonction de la vélocité estimée et du poids en points des éléments. Une nouvelle story d'IceScrum, développée actuellement, est d'améliorer cette planification en prenant en compte les types de release.

Est-ce par télépathie, car cette idée je viens de la présenter chez un client dans le cadre de réflexions sur les forfaits agiles ? Toujours est-il que le développeur de l'équipe en charge de cette story est parti, à son initiative, sur un autre type de release, la release à points (on pourrait dire release à taille fixée). Une release à taille fixée a un objectif défini en nombre de points à faire. A chaque sprint on mesure la vélocité et on diminue le nombre de points restant à faire. La release se termine quand on arrive à 0.

L'idée est intéressante pour les projets au forfait (et pourquoi pas de la TMA) : le contrat porterait sur un nombre de points et le client peut ajuster le contenu et les priorités. Mais cela nécessite d'avoir une équipe stable dont on connait la vélocité.