Estimation

Prioriser, cela permet de définir l’ordre de développement. Dans le cadre de Scrum, la priorisation porte sur les éléments du backlog et indique à l’équipe sur quoi elle va travailler dans le ou les sprints qui viennent. La priorité d’une fonctionnalité est basée sur sa valeur métier, mais pas seulement. Pour affiner l’ordre de cette fonctionnalité et se projeter un peu plus loin que le travail immédiat, il convient aussi de s’intéresser à l’effort pour la développer. Le fameux Planning Poker est une technique d’estimation couramment utilisée par les équipes.

Suite à mon billet d’hier sur Plan de release et incertitudes, j’ai reçu un commentaire qui m’amène plusieurs réflexions. Mon lecteur commence à parler du schéma : Le schéma est facile est 3 colonnes. L’incertitude cumulée sur 6-7 sprints (ex. release de 3 mois avec des sprints de 2 semaines) risque d’être très forte.

Lors de la deuxième journée de l’Agile tour Toulouse, le sujet #noEstimates que j’avais proposé a été retenu pour le premier run de l’Open Space. Nous étions un groupe de 6 ou 7 à en discuter. Le sujet ayant de nombreuses implications, la demi-heure que nous y avons consacrée est passée très vite.

La troisième édition de mon livre Scrum a été publiée il y a un an. Depuis, plus de 2000 exemplaires ont été vendus. Pour ces lecteurs, que je remercie bien chaleureusement, je fournis régulièrement des suppléments en ligne. Voici ceux qui portent sur Estimations, mesures et indicateurs, le chapitre 15 de la troisième édition.

J’ai écrit la préface de Kanban pour l’IT, le livre de Laurent Morisseau, deuxième édition. Voici un nouvel extrait. C’est le pénultième.

J’ai arrêté mon sondage sur les estimations à 100 réponses, c’est plus facile pour calculer les pourcentages. Voici les résultats.

En Espagne, les panneaux indicateurs, comme le balisage, sont plutôt rares sur les sentiers mais ils ont la particularité, par rapport aux français et aux suisses que je connais, de donner à la fois la distance et la durée.

C’est dans ce chapitre qu’est abordé le sujet toujours délicat de l’estimation des stories en points. C’est aussi là que je présente la notion de vélocité et qu’on voit pour la première fois un burndown chart. La planification de release est optionnelle dans Scrum. On n’en a pas toujours besoin. Cependant la plupart des équipes que je connais souhaitent en disposer, ce qui demande des efforts.

On arrive à la réunion de planification du sprint avec une liste de stories prêtes. Ces stories sont déjà estimées : c’est généralement une condition pour les considérer comme prêtes. Leur estimation, faite par exemple avec un Planning Poker, date au mieux de quelques jours (lors des revues de backlog du sprint) et probablement pour certaines de beaucoup plus. À la fin de la réunion de planification du sprint, on connaît beaucoup mieux la difficulté des stories, puisqu’on s’est mis d’accord sur les critères de réalisation et de finition, qu’on a des conditions d’acceptation et qu’on a identifié les tâches pour réaliser la story.

En février, j’avais lancé une enquête “Quelle est votre vélocité moyenne ?” Je donnais comme réponses possibles des plages soigneusement sélectionnées pour une vélocité d’équipe. J’avais ajouté une réponse “je ne sais pas”, c’est classique dans une enquête. Et puis, comme j’étais bien conscient que mon enquête revenait plus ou moins à comparer des vélocités d’équipes différentes, j’avais ajouté une dernière réponse : “C’est du pipeau cette enquête”. Donc ça donnait ça :

L’usage courant est de définir un élément du backlog de produit comme étant une story. Dès qu’on sort de la toute petite échelle, on a besoin d’un élément de plus haut niveau, habituellement c’est la notion de feature qui y répond.

Franck (@DirtyF) m’a demandé ce que je pensais de Perplexité, complexité, vélocité …une autre vue.

Henrik Kniberg est un des gourous de l’agilité les plus intéressants. Il a plein d’idées et les exprime toujours très clairement, ce qui fait qu’on a tendance à faire ce qu’il dit. Le risque est de tomber dans le culte du cargo. Exemple avec le focus factor.

Pour estimer les stories du backlog, le Planning Poker est une pratique désormais populaire. Une séance de Planning Poker prend du temps. Pour estimer un backlog initial de 30 à 50 stories, il faut compter une demi-journée. Trop long pour être pratiqué dans une formation. Depuis 2 ans et demi et la lecture du billet Affinity Estimating de Kane Mar, je l’ai remplacé par l’estimation par similitude. C’est comme sur les photos de classe où on met les petits devant et les grands derrière, il s’agit de trier les stories du backlog selon qu’elles demandent un petit effort, un moyen ou un plus grand.

Un backlog contient des éléments de taille différente, ce qui est reflété par la valeur de l’attribut taille, disais-je dans Scrum le guide etc, page 64. D’ailleurs, certains utilisent les tailles de T-shirt : S, M, L et XL plutôt que la suite de Fibonacci. On retrouvait aussi un attribut appelé taille (size dans la version anglaise) dans iceScrum R2, associé à une story du backlog. Dans la nouvelle version, cet attribut a changé de nom, il s’appelle maintenant effort.

Dans ma formation de la semaine dernière, il y avait un peu plus de la moitié des participants qui pratiquaient déjà Scrum, plus ou moins. Mais au moment de parler de planification de release agile, quand je leur ai posé la question “Estimez-vous en points ?”, il s’est avéré que leurs estimations se faisaient plutôt en jours. Certains avaient essayé les points et avaient abandonné devant les nombreuses réticences de leurs équipes.

C’est un précepte de Scrum et des méthodes agiles : on cherche à maximiser la valeur ajoutée. Plus la valeur d’un élément est importante, plus sa priorité est élevée et, comme la priorité définit l’ordre dans lequel les éléments du backlog sont réalisés, les éléments avec le plus de valeur sont développés en premier. Mais ce n’est pas facile d’estimer la valeur ajoutée par une story…

Les cartes de planning poker servent à estimer. Mais pas à jouer au poker. On peut quand même s’en servir pour des activités ludiques. La preuve en photos, c’était à l’occasion d’un séminaire (en relation avec Scrum et l’agilité) que j’ai animé la semaine dernière. Dans deux des ateliers, nous avons utilisé les cartes de planning poker. Le premier atelier est un jeu, trouvé sur le site de la Scrum Alliance, qui montre l’importance de la communication dans l’équipe. C’est une espèce de bataille muette.

Avec l’expérience on donne moins d’importance aux estimations et à leur justesse, parce qu’on sait que ce qui compte avant tout c’est d’arriver, en faisant de son mieux. C’est comme en randonnée. En montagne, les estimations sont déjà faites pour vous, comme je le remarquais il y a 3 ans dans l’article : La minute idéale du randonneur. Avant je mesurais la durée réelle d’un parcours et en plus, j’étais content si elle était plus courte que celle annoncée sur les panneaux.

Même si on a fait une analyse des risques et mis en place une stratégie de réduction, des impondérables surviennent toujours sur un projet. Un impondérable (impediment) a pour effet de bloquer ou ralentir une ou plusieurs tâches en cours. Pour empêcher ces impondérables de remettre en cause les engagements, il faut se garder du mou lorsqu’on planifie (c’est d’ailleurs aussi une stratégie de réduction des risques).