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:

Les estimations

L’estimation est une manière de représenter la charge nécessaire à la réalisation d’un item pour arriver au résultat demandé.

C’est pour les équipes qui utilisent les estimations probablement la dernière étape pour passer le ticket en ready (DoR)

Pourquoi estimons-nous?

Réduire au maximum les risques

La session d’estimation sert à mettre au jour et diminuer les zones d’ombre et risques du projet.
Une fois ces dernières connues, on peut choisir comment les traiter:

  • Un Spike. Il est utilisé quand on ne connait pas encore la solution technique qui peut être apportée à un problème (idéalement, on fera un ou plusieurs POC).
  • Inclure cette inconnue dans l’estimation.

Servir de support à la prise de décision et à la priorisation

Avant de développer une fonctionnalité, il est intéressant d’avoir une idée de son coût.
Une entreprise qui investit doit pouvoir estimer son ROI (retour sur investissement), cette information servira également dans la priorisation du backlog, c’est la raison pour laquelle il est possible qu’une story
estimée ne soit jamais développée.
Quand une application doit être mise en production, en fonction du nombre de sprint disponible et du
« coût » de développement, on priorisera différemment certaines features.
Faut-il engager plus de développeurs, testeurs, analystes et techniques pour augmenter la valeur livrée?

Établir la confiance

Pour que la confiance règne entre les parties prenantes d’un projet (clients, décisionnaires, PO), il faut
que l’équipe soit fiable sur sa capacité à livrer ce qui est promis. Les estimations nous guident dans
ce que nous devrions être capables de livrer dans un futur plus ou moins proche.
Grâce à cette donnée objective, nous pourrons plus facilement négocier le périmètre des releases

Aligner lʼéquipe et partager lʼinformation

Les estimations permettent de sʼassurer dʼune compréhension commune du périmètre, de la valeur à
produire et de se mettre dʼaccord sur la « taille » dʼune fonctionnalité.

Pour découper les User Stories (US)

Quand nous lisons, comprenons et estimons un ticket, nous pouvons parfois nous apercevoir que cette
dernière est trop importante.
Dans ce cas, nous le divisons en ticket plus petit. Nous augmentons la granularité du backlog et
renforçons la prédictibilité du travail.

Pour organiser le sprint backlog produit du point de vue de la valeur, de l’effort.

Si nous connaissons lʼeffort nécessaire à la réalisation dʼun ticket, nous pouvons déterminer si ce dernier
est réalisable dans le sprint.

Planification

Cʼest également un bon moyen pour estimer le nombre de sprint nécessaire à la réalisation des tickets
souhaités dans une release via un forecast.
On peut également communiquer plus facilement les causes d’un changement de plan, par exemple, si
l’on découvre que l’intégration d’un système à notre application est plus complexe que prévu, on peut
aisément démontrer l’effet sur ce que nous avions prévu.

/!\ Le forecast n’est absolument pas un outil permettant de prévoir avec certitude quand une application serra développée.

PiPo

Que représente une estimation?

Nous allons ici explorer plusieurs hypothèses sur le que/quoi et le comment estimer, selon quelle métrique.

Des jours hommes / du temps?

  • L’humain est incapable d’estimer correctement son temps
  • Une date ne prend pas en compte les facteurs externes tels que les emails, les meeting, les conversations informelles, lʼaide apportée par un développeur à un autre …
    (Habituellement, nous considérons quʼun développeur développe environ 6h/ jour)
  • Le temps / les dates ont une valeur émotionnelle qui finira par oppresser les développeurs et le
    poussera soit à diminuer la qualité de son travail pour gagner du temps, soit à augmenter le temps
    prévu.
  • Le temps nécessaire pour un développeur ne sera pas le même que pour un autre.

Pour illustrer mon propos

Prenons le cas d’une course à pied selon le point de vue d’un analyste ayant fait un Iron Man et d’un
Scrum Master de 110 kg.

Si on demande une estimation en temps pour les 20km de Bruxelles, le premier répondra 2h30, le
second 6h (sans certitude de terminer).
Ajoutons à cela que c’est une tierce personne qui va courir le jour J, il est totalement impossible de prédire le temps qui sera nécessaire. (Même un calcul savant donnerait une réponse erronée).
En revanche, si on demande d’estimer l’effort, la réponse sera pour les deux 20km.
Et si demain on parle d’un marathon, on sait que l’effort est peu ou prou le double.

Pour les tickets, c’est la même chose, si on estime en jours/homme, on doit savoir qui fera la tâche.

De la complexité?

Au plus c’est complexe à réaliser, au plus la valeur de l’estimation serait élevée, et inversement.
C’est en effet un point de départ intéressant, mais qui a ses limites.

Pour illustrer mon propos

Considérons une équipe de deux personnes composée d’un enfant et d’un chirurgien du pied.
Considérons 2 tickets (Nous supposons que les activités prennent le même temps.), construire 1000 personnages Lego et réaliser une reconstitution du pied (le pauvre a marché sur une brique).

Si nous parlons complexité, l’opération du pied aura une estimation bien plus élevée que le montage des personnages.
Si le but était de planifier et de savoir quand l’équipe aurait terminé, puisque le temps de réalisation est plus ou moins identique, l’estimation aurait dû être la même.
En fait, on peut dire que si la complexité des tâches varie, l’effort à fournir est comparable.

Un risque

Dans cette hypothèse, nous considérons qu’au plus le travail est risqué, au plus l’estimation devrait être élevée, et inversement. C’est assez risqué de prendre uniquement cette donnée pour une estimation.

Pour illustrer mon propos

Considérons l’estimation de la durée du voyage maison boulot en transport en commun et en trottinette.
Le transport en commun est plus rapide, mais « risqué » (Présence de bouchon, des gens dans les voies
(oui, la SNCB dit bien dans les voies).
La trottinette, même électrique, c’est plus « sûr », mais c’est lent (oui bon, on ne va pas prendre en considération le nombre de personnes aux urgences après une chute).
Une estimation en risque serait plus élevée pour le transport en commun, cependant, il est tout à fait possible que vous arriviez plus vite en bus qu’en trottinette au boulot demain. (Si demain est un weekend, ne vient pas au bureau).

Mais alors quoi?

Et bien, nous devrions surtout parler d’une notion d’effort qui reprendrait toutes les hypothèses précitées. La quantité de travail à fournir, sa complexité, ses risques et inconnues, le temps.

Quelle mesure pouvons-nous utiliser pour représenter l’effort?

T-shirt sizing

À mon sens, à utiliser pour du haut niveau, par exemple pour se donner une idée avant analyse

Valeurs disponibles:
XS, S, M, L, XL …

Les animaux

De nouveau, nous sommes sur quelque chose destiné à du haut niveau. Avant l’analyse, Épic …

Valeurs possibles:
Puce, tigre, éléphant …

Les StoryPoints

À utiliser pour des tickets pour lesquelles nous avons beaucoup d’informations, voir, plus d’inconnue.

Valeurs disponibles:
1, 2, 3, 5, 8, 13 …

D’autres articles suivront sur ces différentes mesures.

Quand on estime un ticket, ce n’est pas je qui estime, mais nous.
Toutes les estimations sont le résultat d’un travail d’équipe.

PiPo

Pourquoi parler de relativité (E=mc²)?

Reprenons notre exemple de course, si notre première estimation était faite pour une course de 20 km,
nous pouvons aisément estimer que l’effort nécessaire à 10km sera de 1/2 tandis que l’effort pour 40km
sera le double.
De la même manière, les autres mesures permettent à l’équipe un accord sur la taille relative des tickets.
Par exemple, la story 2 représente 1/2 des efforts de la 1. La story 3 représente 2 fois la somme d’effort de la première.

Estimer de manière relative prend en compte l’imprécision de nos estimations. En effet, les humains ne sont absolument pas doués pour ce genre de chose, par contre, ils sont tout à fait capables de comparer 2 choses entre elles.

Revenons à nos Lego, en voyant un tas, vous ne seriez pas en mesure de donner le nombre de briques qui le compose, par contre, vous pouvez comparer 2 tas et dire qu’il y en a plus dans celui-ci.
Vous pourriez également dire qu’ils sont à peu près identiques …

On peut faire le même exercice avec des verres d’eau (ou de Vodka).

  • Le premier verre est la référence
  • Nous pouvons estimer que le second est plus rempli
  • Le troisième est aussi rempli que le 1er (à moitié vide, ou moitié plein …)

It’s difficult to make prediction, especially about the future

Quote Investigator

Points d’attention

Variation du résultat par rapport au travail à fournir

Nous devons garder à lʼesprit que même si lʼéquipe est normalement capable de développer entièrement le produit, nous travaillons avec des spécialistes. Donc, si durant une période donnée, il y a moins de travail dans un domaine, la quantité de travail fournie par l’équipe va mécaniquement diminuer.

Précisions

Il est impossible d’obtenir un chiffre précis quoi que nous fassions.
Par contre, au fil du temps, pour une équipe stable, la corrélation estimation de l’effort et nombre de
tickets done dans un sprint sera de plus en plus exacte, et donc, la prédiction moyen terme également.

Last but not least, les estimations, ce n’est pas SCRUM, c’est XP.

Les critères d’acceptation

A quoi servent-ils?

Ils sont moteurs de communication et de réflexion

Ils déclenchent le processus de réflexion de l’équipe et amènent à penser, à comment une fonctionnalité va se comporter du point de vue de l’utilisateur final (persona)

Souviens toi, une story c’est surtout une amorce à la discussion / réflexion.

Servent de base aux cas de test

Aide l’équipe à écrire des cas de tests précis et sur base des critères accepté par tout le monde et donc cohérent sur l’ensemble de la vie du ticket.

Ils décrivent également des scénarii négatifs , et des unhappy flow

Ils affinent le scope

Définissent la portée, les limites du ticket et réduisent les ambiguïtés. Ils clarifient.

Garantie

Ils garantissent que tous les parties prenantes et utilisateurs ont une compréhension commune et sont satisfaits de ce qu’ils obtiennent.

Ils aident à l’estimation

Ils présentent ce qui doit être exactement développé par l’équipe. Grâce à ces exigences précises, l’équipe peut éventuellement diviser en tâches qui aideront à une estimation globale.
(Du coup, ça aide aussi à diviser une story en « sous-story »)

Les critères d’acceptation sont indispensables, car ils évitent les résultats inattendus et mettent tout le monde d’accord sur la manière dont va être implémenté un ticket.

PiPo

Qui rédige les critères d’acceptation?

Le PO bien entendu …

Tout le monde le sait, le PO, il fait beaucoup beaucoup de chose, donc, il délègue. Il délègue a qui veut / peut le faire dans l’équipe.

  1. Les analystes qui connaissent bien le sujet du ticket
  2. Le métier qui en faisant cela s’assurera que le besoin exprimé sera bien rempli
  3. Le développeur qui confirmera sa compréhension du ticket
  4. Le QA qui va chercher la petite bête, l’incohérence dans le récit

La manière la plus efficace de créer les critères d’acceptation est très certainement un savant mélange des différents rôles et compétences.

PiPo

Quand rédiger les critères d’acceptation?

  1. Avant le développement du ticket. (Merci capitaine Obvius)
  2. Durant les exercices d’affinage du backlog
  3. Durant l’analyse d’une demande métier
  4. A la rédaction de la demande métier
  5. Durant une phase de discovery

Le format

La check liste

  • Critère 1
  • Critère 2
  • Critère n

Le(s) scénaro(ii)

  • Étant donné …
  • Lorsque …
  • Alors …

Pour les critères de scénario, gherkin, c’est pas mal du tout

Autre

Libre à toi de créer un format qui correspond à ton équipe.

N’hésite pas à le proposer en commentaire

Quelques exemples

Consulter la fiche d’un livre sur un site d’e-commerce

En tant que client du site, je souhaite chercher un livre en spécifiant ou son auteur, ou son titre, ou son ISBN afin de consulter sa fiche

La description du contenu à afficher pour la fiche descriptive du livre de même que la mise en page de la liste de résultat sont décrites dans d’autres tickets.

Liste

  • Résultat unique: je peux directement consulter la fiche descriptive du livre
  • Pas de résultat: je suis invité à effectuer une nouvelle recherche
  • Plusieurs résultats: Je suis invité à choisir parmi une liste de livres

Scénario

Un seul résultat

Étant donné que je suis sur la page de recherche du site e-commerce
Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il n’y a qu’un résultat
Alors je consulte directement la fiche descriptive du livre

Pas de résultat

Étant donné que je suis sur la page de recherche du site e-commerce
Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il n’y a pas de résultat
Alors je suis invité à effectuer une nouvelle recherche

Plusieurs résultats

Étant donné que je suis sur la page de recherche du site e-commerce
Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il y a plusieurs résultats
Alors je vois une liste de résultat et peux choisir celui qui m’intéresse

Il est préférable d’utiliser le « je » dans les critères d’acceptation, cela aide à se mettre dans la peau de l’utilisateur, à garder son point de vue et ses besoins à l’esprit

PiPo

Connexion d’un utilisateur non connecté possédant déjà un compte utilisateur

En tant qu‘utilisateur non connecté, je souhaite introduire mon nom d’utilisateur afin d’avoir accès à mon profile

Liste

  • Nom d’utilisateur et password correcte: affichage du profile utilisateur
  • Nom d’utilisateur et / ou password erroné: affichage d’un message d’erreur
  • Nom d’utilisateur et / ou password erroné pour la troisième fois: affichage blocage compte

Scénario

Nom d’utilisateur et password correcte

Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site
Lorsque je saisis mon nom d’utilisateur et mon mot de pass (correcte) et que je clique sur le bouton de connexion
Alors je suis connecté au site.

Num d’utilisateur ou password incorrecte

Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site
Lorsque je saisis une paire d’identifiants incorrecte et que je clique sur le bouton de connexion
Alors je vois un message d’erreur s’afficher: « Votre couple nom d’utilisateur password est incorrecte ».

Num d’utilisateur ou password incorrecte troisième fois

Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site
Lorsque je saisis une paire d’identifiants incorrecte et que je clique sur le bouton de connexion pour la troisième fois dans un temps de 300 secondes
Alors je vois un message d’erreur s’afficher: « Votre couple nom d’utilisateur password est incorrecte, votre compte est maintenant bloqué ».

Ajouter un livre dans le panier

En tant qu‘utilisateur connecté, je souhaite ajouter un livre dans mon panier afin de l’acheter

Liste

  • Le livre peut être livré dans mon pays: le bouton « Ajouter au panier » est disponible
  • Le livre ne peut être livré dans mon pays: le bouton n’est pas affiché, à la place se trouve un message stipulant que le livre ne peut être livré dans mon pays

Scénario

Je suis dans une zone géographique permettant la vente

Étant donné que je souhaite placer un livre dans mon panier et que je suis dans une zone géographique permettant la livraison du livre
Lorsque je suis sur la fiche du livre
Alors le bouton « Ajouter au panier » est visible.

Je suis dans une zone géographique ne permettant pas la vente

Étant donné que je souhaite placer un livre dans mon panier et que je suis dans une zone géographique permettant la livraison du livre
Lorsque je suis sur la fiche du livre
Alors le bouton « Ajouter au panier » n’est pas visible, à la place, un message m’informe que le livre ne peut pas être livré à ma localisation.

Alors oui, je sais, ce n’est pas le meilleur exemple, on pourrait toujours ajouter le livre sans être connecté …

Catégories