On a estimé notre backlog de 80 stories en 2h (extreme Quotation

Toujours au chapitre des estimations (on parlait déja estimation dans le billet précédent), on continue avec un atelier pour estimer rapidement l’ensemble de son backlog. Ici on rentre dans le pratique. On test un atelier d’extreme quotation.

Constat :

  • Donner de la visibilité sur les prochain(e)s semaines/mois aux membres du projet (équipe scrum mais aussi parties prenantes) est primordial pour acquérir confiance et mettre en avant la transparence nécessaire à la réussite du projet.
  • Estimer la charge de travail de façon précise sur les futures fonctionnalités est
    • un exercice impossible/illusoire.
    • très consommateur en temps.
le cône d'incertitude

Avec la durée du projet, l’incertitude est réduite de manière asymptotique, pour atteindre 0% seulement à la fin du projet (par définition). Le nom « cône d’incertitude » provient d’une diminution progressive (au début plus rapide, puis plus lente) de la marge d’incertitude (délimitée par l’estimation plus optimiste ou moins coûteux et le plus pessimiste ou plus cher).

L’atelier Extreme Quotation permet d’estimer rapidement et  de façon macro un grand nombre d’US.

Objectifs 

Sur notre projet les objectifs de l’atelier étaient : 

Objectif principal :

  • Présenter une roadmap estimative aux sponsors et parties prenantes. Le but est de donner de la visibilité.

Objectifs secondaires :

  • Partager/s’aligner sur les prochaines macro fonctionnalités avec la dev team.
  • Lever les loups au plus tôt.
on a trouver le loup ?

Les entrants / prérequis / matériels

  • Des US light (un titre). Nous en avions un peu prêt 80.
    • un carton par US avec 6 sections
      • le type d’artefacts (US, Taches Technique)
      • le thème / épique
      • le numéro de l’US dans jira
      • le titre
      • un cadre hypothèse (non renseigné au début)
      • l’estimation (non renseigné au début)
qui a dit qu'on ne pouvait pas découper les US avec des ciseaux ?
  • Toute la dev team (4 dev).  Les dev ont pris connaissance les jours précédents des US. Ce sont eux et eux seuls qui estiment.
  • La PO dans le but d’observer et éventuellement  (et le plus rarement possible) répondre aux questions de dev.
  • Le Scrum master dans le but d’animer l’atelier et de gérer le chrono
  • Une grande salle avec 2 espaces
    • une table avec toutes les cartes triées par fonctionnalités
    • une table avec 9 colonnes (pensez au scotch de déménagement)
      • 1, 2, 3,5,8,13,20, 40 et ‘?’

Déroulement 

1 – Le scrum master  explique l’exercice, les différentes phases et le timing associé. (5 min)

2- Dans le but de rafraîchir la mémoire à la dev team, le PO a lu le titre de toutes les US.  La dev team ne doit pas poser de question (10 min).

3 – En équipe on désigne une US étalon. C’est à dire une US relativement clair pour tout le monde, et on fixe de façon arbitraire un estimation en points (2 ou 3 points) : (10 min)

4 – Le plus silencieusement possible, les dev prennent une US (celle qu’ils veulent) et la pose dans sur la table des estimations. On estime de de façon relative. L’US va t’elle nécessiter plus/moins de temps à développer que les US déjà placées. (10 min).

Le dev peut “charger” l’estimation s’il juge un risque particulier sur l’US (estimation CURSE ou  inférence bayésienne )

note : en cas de doute, ou de besoins de formaliser une hypothèse,  on peut écrire sur la carte (dans la section hypothèse)

une équipe en ébullition

5-  Une fois toutes les US placées, on fait un second tout où les devs peuvent déplacer les US. En théorie une carte ne pouvaient pas être déplacé plus de 1 fois. C’est à ce moment là que ça c’est compliqué.

Cette phase devait durer 15 minutes, elle en a duré 45 …. car ça un peu diverger,  des échanges parfois un peu long se sont fait sur les adhérences entre US, ou sur ce qui se cachaient réellement derrière. C’est durant cette phase que des incompréhensions/loups ont été levés et c’est plutôt bien.

une estimation en marche

6 – On reporte au stylo les estimations sur les cartes, on range la salle et c’est fini pour l’estimation du backlog. (plus tard il faudra reporter l’estimation dans jira)

Résultat

On a ainsi obtenu un chiffre, une estimation du backlog complet.

On a surtout réussi à mettre toute la dev team sur le même degrés de connaissance et lever un gros loup → une grosse brique technique de resynchro sur lequel nous ne savions pas si c’était sur notre périmètre ou si il existait une équipe dédiée pour la traiter.

Hélas on ne connait pas la réponse mais cela figurera au programme du prochain copil.

Mais au fait l’objectif ce n’était pas d’avoir une roadmap ?

Là on a juste un gros chiffre en point, sans relation avec un temps.

Construction de la roadmap

L’objectif n’était pas d’avoir un nombre de points relatifs à présenter aux sponsors.

Nous voulons une roadmap. Des fonctionnalité qui s’articulent dans le temps avec une estimation des dates atterrissages.

Pour cela notre PO a priorisé les première US à embarquées, et demandé à la dev team quelles US ils pensaient pouvoir prendre sur un sprint.

Cela nous a donné une vélocité théorique (20 points)

Nous avons aussi créer les sprints (une 10ène), en prévoyant à chaque fois un sprint goal théorique -la fonctionnalité phare du sprint-

On a regardé si ça pouvait coller avec la vélocité théorique, et réadapté au besoin et de façon grossière avec des fonctionnalités plus mineurs.

Globalement ça collait. Les sprints faisaient entre 10 et 30 points. Plus les sprints étaient loin dans le temps, plus les variations de points entre les sprints étaient importantes. (retour sur le cône d’incertitude)

Je ne pense pas que l’on puisse faire mieux à ce moment du projet.

En découle une roadmap présentable aux parties prenantes et sponsors

L’objectif imaginé d’une livraison sous 3 mois n’est plus envisageable en état. On en discute ?

On parle alors de décalage de livraison et/ou de descopages de fonctionnalités, et/ou de re-priorisation et/ou staffing d’équipe, bref on avance.

Que pensez vous cet atelier d’extreme quotation ? On se donne rendez vous dans 3 ou 6 mois pour vérifier les chiffres?

 

Ressources 

1 Comment

Add Yours →

Laisser un commentaire