estimation

Prioriser, estimer et planifier

Agile ou pas, il est souvent utile d’avoir des prévisions sur le moyen terme

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.
Prochain Cube Agile à Toulouse : prioriser, estimer, planifier

Prochain Cube Agile à Toulouse : prioriser, estimer, planifier

Comment on priorise ? Pourquoi on estime ? À quoi ça sert ? Qu’est-ce qu’on estime avec Scrum et l’agilité ? Comment faire en sorte que le planning poker ne prenne pas trop de temps ? Comment éviter que la vélocité ne tue l’agilité ? Si, comme de nombreuses équipes vous avez des problèmes avec l’estimation, et par conséquent avec la priorisation et la planification, ce Cube est pour vous.

Discussion à propos de #noEstimates

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. Nous avons tous souhaité continuer cette discussion. Nous avions d’abord envisagé de le faire l’après-midi, toujours pendant l’Open Space.
Chapitre quinze

Chapitre quinze

Estimations, mesures, indicateurs

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. Le but du chapitre Ce chapitre présente les indicateurs d’un développement avec une méthode agile et montre comment les obtenir, avec quelles mesures et à partir de quelles estimations.

Préface de Kanban pour l'IT, cinquième partie

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. Mesures et estimations En réponse à l’exigence de prédictibilité toujours exigée par le management, les méthodes agiles ont réussi, en quelques années, à populariser le planning poker, l’estimation en points et la vélocité. Cependant les dérives liées aux habitudes du contrôle et du micro-management sont apparues de façon concomitante.

Mon enquête sur les estimations

On estime les stories en points

J’ai arrêté mon sondage sur les estimations à 100 réponses, c’est plus facile pour calculer les pourcentages. Voici les résultats. Je demandais quelles étaient les unités utilisées pour les estimations : tâches en heures et stories en jours 19 % tâches en heures et stories en points 35 % stories en points, pas les tâches 34 % stories en taille de T-shirt ou équivalent 4 % #NoEstimates 7 % Mes premiers commentaires :
Panneaux indicateurs

Panneaux indicateurs

J'ai profité des derniers beaux jours pour aller randonner dans le val d'Aran, vers les plus beaux lacs des Pyrénées ; les lacs de Rius et de Tort de Rius sont effectivement des merveilles

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. J’avais écrit en 2007, juste après mon tour des Dents Blanches, un billet sur ce sujet, titré “La minute idéale du randonneur”. Le panneau placé près de l’hospice de Vielha, lui, indique que le Port de Rius est à 4kms et 1h50.
Chapitre six

Chapitre six

Dans la série Suppléments en ligne, voici ceux du chapitre La planification de release

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. Structure du chapitre La carte montre le plan de ce chapitre sur la Planification de Release.

Faut-il ré-estimer les stories pendant la planification de sprint ?

Non

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. A 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.

Mon sondage sur la vélocité

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 :

Estimation de l'effort des features

Estimer les features indépendamment pour mieux les ordonner, les estimer avec les stories pour mieux planifier ou bien ne pas les estimer du tout (pour éviter de perdre du temps) ?

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. Pour bien comprendre cette distinction, le mieux est de s’appuyer sur un exemple ; c’est que j’avais essayé de présenter dans le billet Features et stories écrit en août 2010.

Vélocité, productivité et rock'n roll

Une autre vue sur l'estimation en points, sans la perplexité et la complexité

Franck (@DirtyF) m’a demandé ce que je pensais de Perplexité, complexité, vélocité …une autre vue. L’article est une réaction à Perplexité, complexité et vélocité de Christophe Thibaut. J’avais parcouru le billet original; l’histoire est vraiment très bien racontée mais le fond du message m’avait laissé …perplexe. Après sa lecture, Eric Daspet (@edasfr) a été aussi assailli par le doute. Je suis d’accord avec lui sur plusieurs points : sa réticence à estimer uniquement en fonction de la complexité fonctionnelle, l’oubli des estimations sur les travaux techniques, la confusion entre vélocité et productivité.
L'estimation par similitude d'effort

L'estimation par similitude d'effort

Une alternative au Planning Poker pour faire vite une première planification de release, aussi appelée extreme quotation

Pour estimer les stories du backlog, le Planning Poker est une pratique désormais populaire[1]. 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.

Pas de taille

Encore un effort, coco ! Un backlog contient des éléments de taille différente, ce qui est reflété par la valeur de l’attribut taille, disais-je dansScrum 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.
Estimation en points

Estimation en points

Arrêtez les hommes-jour

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.

Ma présentation Agile Tour en ligne

Estimations, mesures et indicateurs agiles, la présentation que j’ai faite cet après-midi lors de l’Agile Tour de Toulouse (une bien belle manifestation) est en ligne : La prez en pdf Bon, demain je participe à la conférence Scrumpy à Montpellier.