Calcul de la vélocité

Pour initier cette section, je souhaitais aborder la vélocité dont on entend souvent parler dans le vocabulaire Scrum.

Alors tout d’abord, quelques définitions :

Vélocité

la vélocité c’est la capacité à produire, le nombre de points (ou de jours idéaux) que l’équipe peut réaliser en un sprint.

Source :

Attention, si la vélocité sert pour la planification, celle-ci ne reflète pas la productivité. En effet la vélocité peut être modifié artificiellement en gonflant les chiffrages initiaux.

Coefficient de focalisation

Le coefficient de focalisation correspond au rapport vélocité / jours hommes idéaux.

L’objectif étant de mesurer la différence entre le jour homme idéal qui correspond à une journée passé à 100% sur le projet et la réalité.

Source :

Bruit

Le bruit est simplement ce qui empêche le coefficient de focalisation d’être à 1. Une mesure du bruit est donc 1 – Coeff focalisation.

Attention à ne pas confondre les variations dues aux congés, jour fériés etc… et le bruit ! Pour cela, ne pas compter les jours de congés dans vos jours ouvrés, c’est du bon sens.

Mesures et calculs

Vélocité

Pour la vélocité, le calcul est simple, il s’agit de la somme des estimations des tâches réalisés. Si vous utilisez un Burndown chart, cette info se trouve sur votre courbe de reste à faire.

Exemple sur le burndown chart suivant :

bdcsante

L’estimation originale est de 288 heures et le sprint s’est conclu avec un reste à faire de 49 heures.

La vélocité est de 239 heures, soit environ 30 jours de 8 heures.

Coefficient de focalisation

Pour calculer le coefficient de focalisation, il faut utiliser la formule suivante :

vélocité en jours (Cf. chapitre précédent) / ( (Nb jours ouvrés * Nb de personnes affectées au projet) – Nb de jours de congés pris)

Dans l’exemple précédent, avec une équipe de 5 personnes sur 14 jours ayant pris 10 jours de congés :

30 / (5 * 14 -10) = 0.5

Le facteur de focalisation est de 50%

Bruit

Le bruit se calcule à partir du facteur de focalisation :

1 - coeff focalisation

Dans l’exemple précédent :

1 - 0.5 = 0.5 => 50 %

Commentaires divers

Doit-on compter les jours du Scrum master ?

Tout dépend de son rôles sur le projet. Selon les projets le scrum master va agir dans l’équipe en plus de son rôle de Scrum Master. Faisant partie de l’équipe, il agit bien sur la vélocité et doit être comptabilisé. D’ailleurs dans tout les cas il agit sur la vélocité en favorisant l’environnement de l’équipe.

Pour d’autres projets, il se peut que le Scrum Master occupe ce rôle à temps plein et n’ait pas de rôle dans l’équipe ou qu’il joue ce rôle sur plusieurs projets. Dans ce cas, il est possible de ne pas compter ses jours.

Pour faire simple, si le scrum master s’assigne des tâches sur le sprint backlog j’aurais tendance à le compter, sinon non. A vous d’adapter.

Doit-on compter les jours du Product Owner ?

Là encore, rien n’impose formellement que le Product Owner soit comptabilisé dans l’équipe ou non, il faut l’adapter au contexte. Il peut participer à la vie de l’équipe à temps plein, notamment pour la définition des tests d’acceptation ou en support de l’analyste métier mais il peut aussi avoir une participation plus minimale uniquement aux réunions de début de sprint.

Même rêgle que pour le Scrum Master, est-ce que le Product Owner s’assigne des tâches dans le sprint Backlog ? Adaptez à votre contexte.

Doit-on compter les jours des ressources VIP ?

Il arrive effectivement sur les projets qu’une personne intervienne ponctuellement (administrateur de bases de données, urbaniste logiciel etc…). Si cette personne intervient sur 2 jours et n’a plus aucune action sur le sprint, alors non, il ne faut pas compter les jours de ce VIP sur l’ensemble du sprint.

Mais attention à ne pas confondre avec un membre de l’équipe à 50% pour des raisons projets !  (Voir question suivante)

Doit-on compter les jours d’une personne affecté partiellement au projet ?

La véritable question devrait être :

  • cette personne est-elle affecté ponctuellement pour une tâche particulière ? (Cf. ressource VIP plus haut)
  • cette personne est-elle affecté partiellement par contrainte extérieure (autre projet, support de production etc…) ?

Dans le second cas, alors oui il faut comptabiliser l’ensemble de ces jours.

Vous êtes peut-être Scrum Master ou Product Owner et vous vous dites « cette personne est affecté à 50% sur mon projet et je ne souhaite pas faire baisser mon taux de focalisation en comptant les 50% perdus » mais rappelez-vous :

  • la vélocité (qui influe sur ce coefficient) n’est pas un indicateur de productivité et peut être modifié artificiellement.
  • le coefficient de focalisation est une vue objective de l’affectation des ressources au projet, si une ressource est disponible à 50%, votre focalisation baisse par rapport à ce qu’elle pourrait être dans l’idéal, vous vous devez de le montrer

Je le répète, ce coefficient est une donnée de votre projet et vous pouvez souhaitez l’améliorer mais ce n’est pas un indicateur de performance.

En agile, ce qu’on souhaite valoriser c’est le nombre de fonctionnalités livrés utiles pour le client et sa satisfaction par rapport à la qualité et au respect des délais.

Doit-on prendre en compte dans les indicateurs le temps passé en démo, rétrospective et lancement de sprint ?

J’aurais tendance à les ajouter pour les raisons suivantes :

  • les démos font partie du temps passé, elles influent sur le coefficient de focalisation en négatif c’est vrai mais il faut le prendre en compte de toute façon.
  • la rétro concoure à améliorer le process, elle consomme mais devrait rapporter dans le temps
  • la réunion de lancement de sprint permet le découpage en tâches et la conceptualisation technique, du coup elle fait vraiment partie du sprint
  • la démo est l’occasion d’enrichir le product backlog, ce qui est une tâche en soi

En fait si ca influe trop, c’est peut être qu’il faut agir dessus, par exemple une équipe qui ferait des sprints d’une semaine avec réunion de lancement de 4 heures, démo 4 h et rétro 2h, ca ferait beaucoup de bruit pour la durée. Autant le matérialiser quelque part.

A adapter là encore.

 

J’ai lu pour vous : Scrum, le guide pratique de la méthode agile la plus populaire

scrumaubry

de Claude Aubry

Voilà, je viens de terminer ce bouquin. Je désirais avoir un bon livre sur Scrum afin de prendre du recul et revoir les concepts de cette méthodologie que j’avais déjà pratiqué partiellement. Il ne faut jamais négliger la théorie, car si bien souvent on a tendance à la mettre de côté pour favoriser l’apprentissage sur le tas, la revue des fondamentaux apporte toujours un recadrage. Et c’était bien mon objectif, recadrer mes pratiques avec les valeurs auxquelles elles devaient correspondre, comprendre toutes les facettes d’un projet et pas seulement celles propre à l’équipe de développement.

Au final, ce livre a rempli ses objectifs pour ma part, il m’a donné un meilleur éclairage sur les valeurs véhiculées par l’agile et m’a permis de comprendre toute la partie de gestion de la vision produit qui m’était moins familière.

Le début du livre s’attache à donner les bases de l’agilité et notamment la notion de développement piloté par la valeur, la valeur palpable, celle que l’on peut démontrer rapidement à la fin de chaque itération. S’en suit un ensemble de chapitre qui précise les grands rôles d’un projet Scrum : Product Owner, Scrum master et équipe. Pour ma part, connaissant moins le premier rôle j’ai pris plaisir à la lecture des chapitres autour du product owner et du backlog de produit.

On sent d’ailleurs que l’auteur a été Product Owner, car plusieurs chapitres portent sur la formalisation de la vision aux user story et aux tests d’acceptation mais le cycle de développement n’est pas oublié avec des parties sur les mesures et indicateurs, les techniques d’estimation, l’ingénierie du logiciel et les outils.

Par contre, comme l’indique la jaquette du livre, celui-ci s’inscrit dans un contexte de formation personnelle et il se présente moins comme un retour d’expérience comme peut l’être « Scrum et XP depuis les tranchées ». J’aurais peut être aimé un peu plus de mise en situation, de retour sur des expériences réelles. En ce sens, j’ai porté une attention particulière aux chapitres dédié à la transition vers l’agilité : « Adapter Scrum au contexte », « la transition à Scrum » et « Scrum en France ». Ces chapitres donnent tout de même de bonnes informations.

Au final, très bon bouquin formateur sur l’une des méthodologies qui a pris le plus d’ampleur ces dernières années. Ce livre couvre tout les aspects de la méthodologie et se doit d’être lu si on s’intéresse au sujet.