planning poker

Prioriser, estimer et planifier

Prioriser, estimer et planifier

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.
Démarrage 1CUBE&GO réussi à Toulouse

Démarrage 1CUBE&GO réussi à Toulouse

Parmi les 9 Cubes proposés par 1CUBE&GO, j’avais choisi pour cette première celui intitulé : Exprimer et formaliser le besoin. Cette demi-journée -c’est la durée de chaque Cube- m’a permis de partager avec les 9 participants sur les outils et concepts pour aller du besoin initial jusqu’à un backlog prêt. Je leur ai proposé une approche progressive en 4 parties : Impact Mapping, Story Mapping, Features et stories prêtes, Structure du backlog pour le suivi.

Chapitre quinze

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.

Mon enquête sur les estimations

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 %

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.

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

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 :

Votes pour le planning poker

Résultats du sondage Qu’utilisez-vous pour voter lors du planning poker ? Des cartes faites maison 44.58 % Des cartes achetées en ligne 33.73 % Votre smartphone 3.61 % Une application en ligne 4.82 % Vos doigts 4.82 % Votre voix 8.43 % Merci à tous les participants.

Suites pour estimer

L’estimation des éléments du backlog se base sur des suites de nombres. La suite la plus couramment utilisée pour estimer lors d’une séance de planning poker -en tout cas la plus connue- est la suite de Fibonacci. La suite de Fibonacci se présente comme ceci : 0 1 1 2 3 5 8 13 21 34 55 89 Dans les cartes de Planning Poker que l’on trouve en ligne, c’est :
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 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.

Mon blog ne passe pas le contrôle parental !

J’apprends par Fabrice que mon blog ne passe pas le contrôle parental ! C’est dans son billet Scrum, Agilité et contrôle parental. Tout ça à cause du planning poker. Le mot poker fait aussi que, sur mon blog, les commentaires qui parlent de planning poker sont marqués comme des spams. Déjà, quand je faisais du conseil dans une grande banque centrale, ça tiquait quand j’annonçais sur le planning une réunion de planning poker.
Utilisation des cartes de planning poker

Utilisation des cartes de planning poker

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.

Ma présentation de vendredi au SigmaT8

Plein de têtes nouvelles au séminaire de vendredi parmi la cinquantaine de personnes présentes. Ma présentation sur le plan de release (et le planning poker et la vélocité) est accessible sur le site SigmaT ou ici en fichier attaché. La présentation a été filmée par Olivier, mais le son n’est vraiment pas bon. Comme Vincent a enregistré sur son dictaphone avec une meilleure qualité de son, on va voir s’il y a moyen de mixer les deux.

SigmaT8 aujourd'hui à 16 heures

Séminaire gratuit sur les méthodes agiles à Toulouse ! Pour les retardataires, il est encore temps de consulter le programme et de s’inscrire. Vous pouvez même venir sans vous inscrire, il reste de la place. En plus des présentations, il y aura une animation surprise permettant de gagner des jeux de planning poker. Et un apéritif offert à tous.

Programme du SigmaT8

Après le succès de l’Agile Tour du 16 octobre, nous reprenons les séminaires trimestriels à Toulouse. En attendant de nouvelles formules pour 2009. Donc le prochain SigmaT, le 8ème en 2 ans, aura lieu le 12 décembre. Un programme varié, avec un retour d’expérience, de la modélisation agile et un sujet que je présenterai sur la planification de release. Le 16 octobre nous avions distribué aux premiers inscrits des cartes de planning poker.

Zorro est revenu

La valeur et le coût, c'est pas pareil

Dans son deuxième commentaire de mon billet sur la variation de périmètre, Zorro revient sur les courbes et s’y perd entre les notions de valeur, d’effort et de coût. J’essaie d’éclaircir. Le burndown chart montre l’effort qui reste à faire. Il est obtenu en collectant le nombre de points des éléments qui restent à faire dans le backlog de produit. Exemple : début du sprint 1 : 100 points à faire fin du sprint 1: 82 fin du sprint 2 : 64 fin du sprint 3 : 56 fin du sprint 4: 30 Il ne permet pas de connaitre la part due au travail accompli et celle venant du changement de périmètre dans le backlog.

Des cartes pour jouer à quoi ?

Au poker ? Au planning ? Les 100 premiers inscrits à la conférence Agile Tour de Toulouse ont reçu des goodies. Dans le sac estampillé Agile Tour, il y avait un jeu de cartes pour le planning poker, grâce à notre sponsor Agile Hardware. Certains qui étaient venus découvrir l’Agilité ont dû se demander quoi faire avec ces cartes et l’explication n’a pas été donnée pendant la conférence, puisque le sujet n’a pas été abordé.

L'Agilité en situation

Le prochain séminaire agile de Toulouse constituera une étape de l’Agile tour. Il se tiendra le 16 octobre, sur toute l’après-midi. J’y ferai une présentation avec Philippe Kruchten. Le programme présente un résumé de la présentation. Les idées présentées iront à l’encontre de plusieurs croyances sur l’agilité : des personnes sont persuadées que leurs pratiques agiles sont universelles et peuvent s’appliquer partout, certaines pensent être agiles parce qu’elles appliquent 2-3 pratiques qu’elles considèrent agiles, d’autres disent que l’agilité c’est sûrement très bien, mais croient que c’est totalement incompatible avec leur organisation.

Planning de release

Un plan de release permet d’avoir la connaissance actualisée de ce qui va être fourni au long des sprints de la release. C’est une projection du backlog sur les sprints qui constituent la release. Je viens de mener, cette semaine et la semaine dernière, 2 sessions de planification de release, pour 2 projets différents. La planification de release faite la semaine dernière a été effectuée alors que l’équipe avait déjà déroulé 5 sprints.
De nouvelles cartes pour le Planning Poker

De nouvelles cartes pour le Planning Poker

Estimer devient un jeu...

J’avais déjà quelques jeux de cartes pour le Planning Poker. Je viens de recevoir de nouvelles cartes, fabriquées par PlanningPokerCards.com. Avec ça, je peux faire des séances d’estimation du coût de développement pour de belles équipes. Le Planning Poker commence à avoir du succès comme technique d’estimation. On trouve des cartes sur Internet, on en parle dans des blogs et on l’applique sur le terrain. Parfois on en fait sans le nommer comme ça, en disant simplement réunion d’estimation ou réunion de planification en commun parce que jouer aux cartes dans une entreprise c’est pas dans les moeurs.