La définition de fait DoD

Le début de la fin

Qu’attendre de cet outil?

  1. La DoD aide à déterminer si un item du backlog de sprint (US par exemple) peut être considéré comme terminé.
  2. Elle fluidifie le travail des développeurs (codeur)
  3. Aligne l’équipe technique et métier sur le résultat attendu en fin de sprint.
  4. Évite les allez retours et les déceptions
  5. Elle est garante de la qualité du produit
  6. Un accord sur la notion de terminé

Une fois que l’élément de backlog répond à ces critères, il peut être déployé.

Que dit le guide SCRUM

La Definition of Done (Définition de Fini) est une description formelle de l’état de l’Increment lorsqu’il satisfait les mesures de qualité requises pour le produit.

Dès qu’un élément du Product Backlog satisfait à la Definition of Done, il se transforme en Increment.
La Definition of Done apporte de la transparence en permettant à chacun une compréhension commune du travail Fini dans le cadre de l’Increment. Si un élément du Product Backlog n’est pas conforme à la
Definition of Done, il ne peut pas être publié ni même présenté lors de la Sprint Review. Il est alors renvoyé au Product Backlog pour être pris en compte ultérieurement.

Scrum guide 2020

Exemple de définition de finit – DoD

  1. La revue de code a été effectuée
  2. Les critères d’acceptations du ticket sont tous validés
  3. Les différents test ont été réalisés et le résultat accepté par les différents acteurs de la qualité du produit (PO, Codeur, Testeur, …)
  4. La doc nécessaire a été mise à jour
  5. Les maquettes graphiques sont respectées
  6. Livré dans un environnement stable (possible en DevOps)

Il est tout a fait envisageable que selon le contexte (frontend, API, …) des parties de la DoD ne s’appliquent pas à certains ticket. (Storyotype)

Attention tout de même …

La definition of done ne doit pas être une liste infinie de critères impossible à terminé durant le sprint.
Elle est un engagement fondamental de l’équipe a fournir un ticket finit et ne dois pas devenir une contrainte (dans le sens difficilement réalisable)

La définition doit rester simple pour être comprise par l’ensemble de l’équipe du projet.
Il n’est pas non plus utile de chercher la sur-qualité et de mettre les objectifs de sprint en difficulté.
Il est inutile de commencer par une définition super élaborée, nous l’affinerons avec le temps.

Elle évolue

Comme mentionné auparavant, on amendera la définition, donc à un moment, des items réputé « done » ne correspondront pas à cette définition.

Le mot de la fin

  1. La DoD aide à augmenter la qualité d’un ticket
  2. Elle est le fruit d’une discussion ouverte entre tout les membres de l’équipe.
  3. Elle n’est pas figée dans le temps et donc évolue en fonction de la maturité de l’équipe
  4. Ses principaux avantages sont l’optimisation de la rédaction, de l’estimation, le gain de temps lors du sprint planning

Attention, la DoD ne doit pas être un frein, elle ne doit pas être une liste à rallonge de critères qui sont peu ou pas utiles à l’équipe, elle doit être réalisable, ajustable et adaptée à l’équipe du projet.

Qu’est-ce que la vélocité

La vélocité, c’est « l’effort » moyen qu’est capable de réaliser une équipe sur une période donnée.
(Une quantité de sprint par exemple).
Cet effort peut être exprimé au moyen de story points

Exemple de calcul

Voici quelques données nécessaires à la compréhension d’un calcule de vélocité.
Comme tu le constates, il y a une grande différence entre les sprints 8 & 9 et les autres.
De temps à autre, il arrive que l’équipe ne finisse pas tout ce qu’il y avait dans le sprint, je t’invite à lire l’article Le sprint est fini, et il reste des tickets
Les points brûlés correspondent à l’addition des SP des items réalisés. Répondant à la Definition of Done (DoD)

SprintPoints brulé dans le sprint
Sprint 725
Sprint 811
Sprint 937
Sprint 1024
Sprint 1126
Donnée nécessaire à un calcul de vélocité
Graphique de vélocité sur 5 sprint

Nombre total de points pour les 5 sprints: 123
Nombre moyen par sprint / vélocité: 24,6

Est-ce toujours fiable?

Pas nécessairement, c’est une excellente indication, mais certains facteurs vont influencer les chiffres.

Les jours de maladie / congé

Si un développeur ne travaille pas et donc ne développe pas, il y a moins de choses qui sont réalisées au courant du sprint => moins de SP brûlé.

Si nous fonctionnons en flux tendu (c’est-à-dire que le temps entre la rédaction des tickets et leur apparition dans un sprint est relativement court), on pourrait également se retrouver avec moins de choses à faire, ou des choses non encore bien décrit et répondant à la DoR. Dans ce cas, le travail de développement sera également impacté.

Oui, mais bon, tous les développeurs sont au moins une fois malades sur l’année, donc, on peut lisser cette donnée.
Ce n’est pas faux, mais ce n’est pas tout à fait vrais non plus, on reviendra sur cela plus loin dans l’article.

Au plus l’équipe est petite, au plus ce facteur aura d’influence (100% pour une équipe de 1 dev).

Les changements dans l’équipe

Alors ici, c’est très simple, si l’équipe n’est pas stable depuis un certain temps, cette information n’a absolument aucun sens, aucune fiabilité, aucune valeur.

  • En cas de nouveau venu, du temps à consacrer à son intégration, à la place du développement des tickets.
    En théorie, on reviendra à la situation initiale et à une augmentation après un certain temps. Si ce n’est pas le cas, il y a des questions à se poser.
  • Un membre de l’équipe part, il y a donc moins de « force de travail » disponible

À tous les coups, un changement dans l’équipe modifie la vélocité.

La spécialisation des membres de l’équipe

Une équipe doit être en mesure de réaliser l’entièreté du produit, cependant, ses membres ont certaines spécialités. Il est tout à fait envisageable dans un projet de développement d’une application ou d’un site qu’un sprint contienne plus de demande front-end que back, dans ce cas, un spécialiste back-end peut se retrouver sans ticket dans sa spécialité. Bien entendu, il ne va pas rester à rien, mais il est certainement moins compétent dans les autres domaines.
PS c’est probablement un bon moment pour régler un peu de dette technique (qui ne devrait pas exister) ou aider à l’analyse, ou optimiser du code …

Que peut-on faire avec cette information?

Prévoir le nombre d’item à mettre dans un sprint

Cette mesure nous permet par addition des SP de savoir quelle quantité de tickets nous pouvons mettre dans le sprint.

Planifier

On peut faire un forcast, c’est-à-dire qu’on peut tenter de prédire, d’estimer et donc de planifier quand une fonctionnalité aura été développée.

Considérons qu’en additionnant les story points des tickets nécessaires à la réalisation d’une fonctionnalité, on arrive à 94. Nous savons que notre moyenne / vélocité est de 24,6

94 / 24,6 = 3,82.

Il nous faut donc 3,82 => 4 sprints pour réaliser la fonctionnalité.

Quelle période de temps devons-nous considérer?

On serait aisément tenté de dire qu’au plus la période de référence est longue, au plus la mesure est fiable. Après tout, on a plus de données …

Et bien non, la vélocité va varier avec le temps. Nous avons déjà soulevé le cas de l’augmentation ou diminution du nombre de membres dans l’équipe, nous allons donc considérer que l’équipe reste stable.

Il y a d’autres phénomènes qui feront varier cette information, par exemple, la montée en compétence technique des membres, la manière d’écrire les tickets va évoluer avec le temps, idéalement devenir meilleure, les membres de l’équipe vont mieux se comprendre et l’estimation deviendra plus précise.

On considère l’information comme correcte après 3 à 5 sprints. Sachant que cette valeur évolue légèrement au fil du temps, utiliser un forcast à long terme n’est pas idéale. Au plus le calcule se fait dans le futur, au moins l’information a de valeur.

Donc, on ne peut pas facilement considérer la possible absence d’un membre durant 4 semaines sur l’année ou même un prorata

Il est tentant de comparer les vélocités propres des équipes, ou de faire un prorata par développeur.
Hé bien, cela ne fonctionne pas, car les estimations pour l’équipe A ne sont pas les estimations l’équipe B.

La lecture de ces articles te sera certainement utile:

Le sprint est fini, et il reste des tickets

Oups, nous n’avons pas terminé tout ce que nous avons promis …

Pourquoi est-ce qu’il reste un / des tickets dans le sprint

La première étape est de déterminer pourquoi nous n’avons pas terminé le sprint.
Nous devrons également répondre à la question suivante: « Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction ».

Une question de capacité

Dans le cas d’un début de projet, il est probable que nous n’ayons pas encore trouvé notre vitesse de croisière, nous remplissons donc le sprint en tâtonnant jusqu’à savoir ce que nous sommes capables de réaliser au cours de la timebox.

Un changement dans l’équipe entraine une perturbation (dans la force).
Une personne en moins diminue d’office la capacité de réalisation de l’équipe, logique me diras tu, cependant, une nouvelle recrue va également diminuer la vélocité (dans un premier temps)
Quand un nouveau rejoint le projet, il va devoir prendre connaissance du métier, de la problématique que l’équipe résout par son travail, il va également apprendre le fonctionnement de l’équipe, et pour ce faire, les autres membres de l’équipe vont perdre investir du temps pour le former.
Donc, en plus de ne pas bénéficier tout de suite d’une augmentation de vélocité, nous allons également en perdre.

Attention, la perte de vélocité doit être à court voire moyen terme, si cette perte perdure, il faut envisager que la nouvelle recrue a été mal intégrée, qu’elle ne correspond pas au projet ou encore que l’équipe devient trop importante et ne se synchronise plus correctement.
Dans tous les cas, il faut agir.

Une mauvaise estimation

Et oui, une estimation reste une science inexacte, de temps à autre, nous nous trompons. Nous surestimons ou sous-estimons. La plupart du temps, nous arrivons à l’équilibre.

Une erreur de compréhension

Nous sommes humains, nous avons plein de possibilités de ne pas nous comprendre, alors, oui, il arrive que nous comprenions une chose alors que ce n’était pas du tout ça.

À la revue par les pairs, nous nous rendons compte que ce n’est pas du tout ce qui était demandé.

  • Ah zut, je n’avais pas ben compris, et je n’ai pas anticipé ces changements, c’est plus compliqué, ça prend plus de temps …
  • Ah, en fait, maintenant que j’ai compris, je vois que nous avons une dépendance vis-à-vis d’une autre équipe, d’un autre fournisseur …
  • Ah, l’équipe a changé entre le moment ou ce ticket est passé à prêt et le développement (Oui oui, ça arrive)

Que faire avec les tickets que nous n’avons pas terminés durant notre sprint?

Il n’y a pas de réponse simple, c’est au cas par cas.

La logique voudrait que s’il y avait un ticket X dans le sprint venant de se terminer, c’est qu’il faut le réaliser, donc, hop sprint suivant.
Cependant …

  • La fonctionnalité à développer arrive trop tard, et n’a donc plus de raison d’être.
  • Le produit a pivoté, la fonctionnalité n’est donc plus aussi prioritaire, voir, plus nécessaire.
  • D’autres items ayant une priorité plus élevée sont apparus dans le backlog
  • L’item ne peut pas être réalisé, car il y a des dépendances non résolues

Pour ma part, je considère que si un ticket a été commencé, il est préférable de le terminer.
En effet, si nous laissons les changements tels quels, suite aux autres évolutions, le travail sera probablement entièrement à refaire pour être intégré dans la solution qui aura évolué. (Tout en prenant en compte les points précédemment cités)

Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction

Heu, ben oui, en fait, il sert à quoi le daily, si ce n’est justement faire un topo sur la santé du sprint, inspecter au jour le jour que nous pouvons respecter le sprint goal et réaliser tout le contenu initialement prévu.po
Si nécessaire, nous nous devons de réaménager le contenu du sprint en accord avec les dev et le PO tout en respectant le sprint goal.

Tout ça pour dire que ça ne devrait pas arriver car nous devrions avoir géré le problème en amont.

PiPo