Définition de fini à la fin d'un sprint
Done done
La mécanique de Scrum repose sur la réalisation d’un élément du backlog en un sprint. A la fin du sprint, l’élément du backlog sélectionné pour ce sprint est normalement fini.
Fini ? Fini fini, c’est le credo de Scrum ! Et quand c’est fini, ça ne recommence pas !
Fini ne signifie pas la même chose pour tout le monde. Lors de mes formations ou de mon coaching, je pousse les équipes à définir leur notion de fini et à l’afficher.
Cela peut être simplement :
- démontré avec succès lors de la revue de sprint
Cela peut aller beaucoup plus loin. Lors de ma dernière formation, le brainstorming avec l’équipe a abouti à cette définition de fini pour une user story :
- codé en suivant le standard de codage
- testé unitairement
- tests d’acceptation passés avec succès dans un environnement de test
- version disponible en français et en anglais
- documentation marketing rédigée
- documentation utilisateur rédigée
Influence de la définition de fini
- Lors de la réunion de planification, penser à ajouter les tâches permettant de respecter ce qu’on attend pour finir un élément du backlog. Par exemple si la définition de fini inclut la rédaction de la doc utilisateur, il faut une tâche pour cela.
- Quand l’équipe s’engage pour le périmètre d’un sprint, elle doit le faire en fonction de sa définition de fini.
- Pendant le sprint, des contrôles sont effectués pour s’assurer que c’est bien fini.
- Lors de la revue de sprint, l’équipe ne montre que ce qu’elle a fini.
- La décision de considérer un élément du backlog comme fini dépend -évidemment- de la définition élaborée par l’équipe. Si elle inclut la disponibilité d’une version en plusieurs langues et qu’à la fin du sprint il n’existe que le français, l’élément ne devrait pas être considéré comme fini. Cela influe donc sur la vélocité.
En l’absence de définition de fini, c’est normalement le Product Owner qui décide, à la fin du sprint, de ce qui est vraiment fini. Avoir une définition élaborée par toute l’équipe évite d’avoir une trop forte dépendance de la décision du Product Owner. Il existe des PO qui, manquant d’implication, ne sont pas assez disponibles pour passer des tests d’acceptation et, souvent à cause de leur culture de MOA, sont méfiants et ont du mal à considérer que quelque chose est vraiment fini.