La définition de fini porte sur la qualité du produit. Elle se présente comme une liste des vérifications permettant de s’assurer de l’état du résultat à la fin du sprint; s’applique à une story pour statuer sur sa finition (traduction de definition of done).
Dans le domaine de la publication papier, il y a des process. Surtout à la fin, quand on arrive à la phase dites des épreuves. Avec mes éditions successives de Scrum et L’art de devenir une équipe agile, cela fait la 7e fois que je passe par les épreuves. C’est toujours aussi éprouvant, car c’est la fin des itérations d’amélioration à peu près libres pour un cadre plus contraint. Et surtout, cela annonce le bon à tirer ce qui pousse à considérer le niveau de finition qu’on veut pour le livre.
Mon blog a commencé en 2006, je vais essayer de le garder toujours vert. Ma résolution, début 2021, était de le rendre persistant. Pour cela j’ai essayé d’appliquer une nouvelle définition de fini. Bilan début 2025.
J'ai lu la version française du Guide Scrum, publiée le 18 novembre 2020. Plutôt que garder mon ressenti pour moi, je vous le partage.
La parution d’une nouvelle version du Guide Scrum suscite toujours beaucoup de réactions. C’est le signe d’un intérêt qui ne se dément pas pour Scrum. Pourtant, et bien qu’il soit et reste une référence, c’est mal écrit, très mal traduit et sans la moindre illustration. L’effort de simplification de cette nouvelle version est louable, mais de mon point de vue, c’est raté.
Après Jimmy, c"est Élodie qui a commenté mon billet la vie de la story. Elle me fait des remarques très intéressantes, j’y réponds en dessous, dans un ordre revu.
Suite à mon article d’hier, j’ai reçu un commentaire de Jimmy L. que je remercie de son feedback.
Jimmy est tout à fait d’accord avec moi pour ne montrer à la revue qu’une story déjà déclarée finie. Cependant il enchaîne :
…Mais cela m’étonne justement qu’on s’arrête généralement à “Finie” sur ce genre de workflow, et qu’on ne mette pas au moins en bout l’état correspondant à l’avis positif reçu en revue de sprint.
Dans l’édition 4 de mon livre, j’ai ajouté des histoires pour raconter une journée typique d’un Scrum Master et d’un Product Owner.
On commence par la celle de Nicolas, le Scrum Master chez Peetic.
Voici l’extrait tiré du chapitre 5 Le rôle du ScrumMaster. J’y ai ajouté, pour ce billet, des notes qui renvoient aux pratiques évoquées.
Douze cases pour placer chaque élément de la définition de fini
La définition de fini est le plus souvent une simple liste. Pour être plus pertinent, on peut définir plusieurs niveaux de fini, et pour être plus complet, plusieurs aspects de la finition.
La définition de fini constitue le chapitre 11 de la troisième édition
Dans la série Suppléments en ligne de mon livre sorti, pour la première édition, il y a 4 ans, voici la Définition de fini qui constitue le chapitre 11 de la troisième édition.
Le résumé en fin du chapitre :
La définition de fini est la pratique qui permet d’obtenir le niveau de qualité attendu à la fin de chaque sprint, pour éviter d’accumuler de la dette technique.
Est-ce que l'équipe est capable de commencer et de développer cette story, compte tenu de ses moyens ?
Une story est prête à prendre le départ du sprint si son comportement attendu (conditions d’acceptation) et la qualité requise (critères de finition) sont suffisamment connus de l’équipe. Un autre volet essentiel pour s’assurer de la capacité de l’équipe à développer la story pendant le sprint porte sur les conditions de réalisation.
Qu’y a t-il dans la définition de prêt d’une story ?
Il est préférable que toutes les compétences nécessaires pour finir une story soient dans l'équipe. Pas à l'extérieur
L’équipe dont j’ai parlé dans le billet Définition de prêt et sprint fait des sprints de 4 semaines. Lors du dernier sprint, le burnup en stories est monté tardivement, en gros de nombreuses stories ont été déclarées finies vers la fin du sprint. Une ou deux autres n’ont pas pu être déclarées finies. Voyons pourquoi.
La question était :
3 équipes Scrum participent au développement d’un seul produit, chacune s’occupant d’un ensemble de features. Comment gérer la signification de fini ?
La question était la suivante :
La signification de fini dit que les tests de performance doivent être passés à chaque sprint. L’équipe n’y arrive pas. Que faire ?
Le retour d’expérience d’Atchik Real-Time présenté au SigmaT9 vendredi a montré que l’équipe s’améliorait continuellement grâce aux rétrospectives. Une amélioration qui a retenu mon attention est celle de la définition de fini.
L’équipe a mis en place une matrice, avec en lignes une liste de contrôles possibles sur les stories et en colonnes les stories sélectionnées pour le sprint courant. Pour chaque story, une croix dans une ligne signifie que le contrôle correspondant est à faire. La matrice est définie par l’équipe en début de sprint.
Des exigences de localisation ou d'utilisabilité représentent des contraintes qui portent sur plusieurs user stories
J’alimente le backlog de produit d’IceScrum pour la nouvelle release. J’y mets donc des features et des user stories, qui représentent l’aspect fonctionnel. Pour avoir un produit de qualité, je réfléchis aussi aux exigences non fonctionnelles. J’avais fait un billet “que faire avec les exigences non fonctionnelles ?” il y a quelque temps en disant qu’elles devaient aussi aller dans le backlog. Mais ça ne marche pas avec toutes.
