Utilisation du résultat du sprint

À la fin d’un sprint, le résultat attendu est un incrément du produit final, qui est potentiellement livrable. Quel usage en fait-on ?

Ce billet reprend une partie du livre Scrum le guide pratique de la méthode agile la plus populaire, chapitre Des sprints pour une release, pages 22 et 23.


En plus de sa démonstration à la revue de sprint, on peut identifier trois usages de la version produite en fin de sprint, pour un développement de logiciel.

Utilisation interne

La version n’est pas utilisée en dehors de l’équipe de développement. Elle a été produite pour chercher à minimiser les risques liés à la technologie et à la capacité de l’équipe à intégrer différents composants. Elle n’est pas livrée à l’extérieur de l’équipe. Cela est fréquent au début d’un nouveau développement.

Utilisation pour feedback par des utilisateurs sélectionnés

La version est utilisée par un client ou des utilisateurs privilégiés. Cela leur donne la possibilité de la prendre en main, ce qui permet de réduire les risques portant sur l’interface. Ces utilisateurs pourront évaluer la facilité d’utilisation des fonctionnalités et en proposer de nouvelles. Les retours faits iront alimenter le backlog pour une prise en compte ultérieure.

Mise en production

La version est mise en production ou en exploitation et utilisée par ses utilisateurs finaux. C’est évidemment ce qu’il faut viser puisque chaque nouvelle version apporte de la valeur. Autant l’apporter le plus tôt possible, dès qu’elle est disponible. Mais ce n’est généralement pas faisable de mettre en production à la fin de chaque sprint : trop de temps serait pris, par rapport à la durée du sprint, pour passer les tests de recette sur tout le système, pour déployer sur l’environnement de production, pour écrire les manuels utilisateurs, pour préparer et donner la formation aux utilisateurs...

C’est pourquoi, dans la plupart des cas, l’état du produit à la fin de chaque sprint est distingué de celui souhaité à la fin d’une release. Mais si on réussit à automatiser le déploiement et à limiter le temps pour le faire, on peut alors mettre en production plus souvent qu’à la fin des releases. Dans ce cas-là, le produit n’est plus simplement potentiellement livrable à la fin de chaque sprint, il est livré. Le terme de release garde son sens de période de temps pour la planification.