Estimation en commitment-driven planning

C’est l’heure d’estimer ou de chiffrer ?

Nous sommes en sprint planning. Le product owner, la dev team et le Scrum master sont présents. C’est l’heure d’estimer l’incrément qui sera livré en fin d’itération. Voyons comment fonctionne l’estimation en commitment-driven planning.

Nous avons 1, 2, 3 ou 4 heures pour

  • Décider quelles stories vont être embarquées dans le sprint à venir
  • Définir le sprint goal, qui pourra nous permettre de garder le cap en cours de sprint malgré des toujours possibles aléas.

Aujourd’hui attardons nous sur le premier point : comment la dev team décide et s’engage sur les users stories qu’elle va développer.

Ces stories ont déjà été travaillées, raffinées par le passé et on les a déjà estimées,mais à la louche. (on n’est pas rentré dans les détail technique). On a pu utiliser par exemple l’outil planitpoker pour celà.

Nous pouvons connaitre notre vélocité moyenne, et donc prendre autant de stories que celle-ci. C’est l’approche Velocity-Driven Sprint Planning

Le problème avec cette démarche c’est que l’estimation à la louche que l’on a fait il y a quelques temps est prise comme argent comptant. Cette estimation a ces limites :

  • elle utilise une suite favorisant justement les estimations type suite de Fibonacci -> donc par essence ce n’est pas précis.
  • elle ne se base pas sur l’effectif réel de l’équipe présente sur le sprint -> tous les sprints ne se ressemblent pas
  • l’estimation se base sur un ressenti après avoir compris le fonctionnel, et non pas sur un découpage technique. Il était trop tôt / non nécessaire à l’époque de faire le découpage technique
  • l’estimation n’est pas forcément réalisée par toute la dev team.
  • l’estimation couplée à la vélocité est un outils pour construire une roadmap, pour évaluer la fenêtre atterrissage du projet ou de grosses fonctionnalités (épique). Mais ça reste du théorique. S’engager sur une vélocité constante est un vœu pieux, démotivant pour l’équipe de dev. De plus elle implique des problèmes d’encrages : On ne pensera pas que l’on peut faire beaucoup plus (ou beaucoup moins) que cette vélocité qui nous est mise sous le nez.

le commitement driven planning

Ce que propose l’estimation en commitment driven est différent.

  • On prend les stories une à une (priorisées par le PO).
  • Puis on les découpe en tâches techniques (cela peut avoir été fait en amont, lors des raffinements, mais quoi qu’il arrive on prend le temps de ré-examiner le découpage).
  • On chiffre en jours/heures ces tâches techniques.
  • Enfin la dev team valide qu’elle peut embarquer cette US dans le sprint.
  • et lon passe à l’US suivante.

On peut même aller plus loin. C’est à ce moment que la dev team s’approprie le sprint. Elle peut déjà imaginer qui va développer chaque tâche technique et quand. On peut être très précis, et faire le planning du sprint à la demi-journée (c’est plus facile sur un sprint court, 1 semaine par exemple).

L’équipe va ainsi, suivant les compétences présentes, pouvoir dire “stop plus d’US avec des taches techniques iOS, mon planning est complet.”

Bien sûr avec l’expérience, on peut être un poil moins fin. A voir si cela fonctionne toujours. Au scrum master de s’assurer que l’engagement est toujours maîtrisé.

On arrive a quelques choses de très fin, c’est ce qu’il faut avant de démarrer le sprint. L’équipe se projette dans le sprint. Le sprint a déjà commencé à vrai dire.

Une fois l’engagement de l’équipe en poche, on peut ensemble vérifier la vélocité cible du sprint.

Pourquoi arrive t’on à une vélocité différente de notre vélocité moyenne. Qu’a t’on raté lors des estimations du grooming, ou a t’on raté quelque chose aujourd’hui dans le sprint planning, quelque chose que nous avions vu au raffinement. On ne cherche pas à ajouter ou enlever des stories du sprint, mais améliorer nos prochaines estimations, pour pouvoir avoir une fenêtre atterrissage du projet le plus juste possible.

Les freins

le temps ! Le planning basé sur la vélocité est rapide. On sait qu’on prend 32 points. Alors on prend de la stories jusqu’à faire 32 points (on peut pousser à 35 pour mettre un challenge #carotte). Et voilà sprint planning terminé. Tout le monde retourne bosser.

On peut/doit voir les choses différemment : durant ce point il faut prendre son temps, lever la tête de l’eau, et ne pas annoncer n’importe quoi. Prendre une après midi pour se projeter dans le sprint n’est pas de trop.

On n’arrête pas de chiffrer, c’est quand travaille t’on? : En complément du premier point. L’équipe estime en point (ou taille de tee shirt, ou piste de ski, etc.) lors de raffinage, puis chiffre à nouveau lors du sprint planning. C’est pénible, c’est fait en double. Autant le faire une bonne fois pour toute.

Et bien non ! Le problème peut alors venir du fait que l’on prend trop de temps à estimer la première fois. Direction l’extrème quotation.

Le problème peut aussi traduite que l’équipe n’est justement pas engagée, elle ne prend pas au sérieux ces chiffrages. De toute façon, on verra ce que l’on va faire, si on fait moins, c’est pas grave, si on fait plus… bah on verra. A ce moment là on touche à la motivation de l’équipe, aux compétences (on sait pas chiffrer, on se plante toujours). Mais la raison peut aussi venir de la posture du scrum master, du PO ou du management. On sort du scope de ce billet.

et pour conclure

Chiffrer sans se baser mécaniquement sur la vélocité, c’est demander un réel engagement (ou prévisionnel) à l’équipe de dev. On touche à une valeur du scrum (l’engagement). Passer le temps nécessaire durant le sprint planning pour faire le tour de chaque stories favorise une autre valeur scrum : le focus.

Préparer un sprint, c’est d’abord bien s’échauffer, et comprendre et se mettre d’accord sur les objectifs de la prochaine course.

Alors on test le commitment-driven planning au prochain sprint planning ?

Ressources :

2 Comments

Add Yours →

Laisser un commentaire