planification

Feedback sur la planification

Feedback sur la planification

noEstimates

Pour l’édition 4 de mon livre, j’ai revu complètement le chapitre qui porte sur la planification à moyen terme. J’ai fait un gros effort sur le pourquoi. J’ai commencé le comment par un exemple simple, sans estimation. J’ai introduit des variantes à l’estimation et au planning poker. J’ai essayé d’illustrer les notions présentées. Je l’ai également déplacé, car cette notion ne fait pas partie du cœur de Scrum. C’est maintenant le chapitre 16, il s’appelle Planifier la release.
Les 6 activités de planification du sprint

Les 6 activités de planification du sprint

La planification du sprint (en anglais Sprint Planning) est un événement Scrum qui se déroule à chaque début de sprint. L’objectif de la planification est de mettre l’équipe en situation de réussir le sprint en se focalisant sur un objectif et s’accordant sur des stories. Voici les activités qu’on y mène : Voici un enchainement possible des activités : L’équipe embrasse le contexte du sprint. Pour chaque story prête, en commençant par la première, l’équipe confirme avec le PO sa confiance pour la finir dans le sprint.

Planifier la release

Pourquoi prévoir à un horizon plus lointain que le sprint ?

Dans l’édition 4 de mon livre Scrum, la présentation de la planification de release a été repoussée. Planifier la release constitue maintenant le chapitre 16. Dans les éditions précédentes, elle était présentée avant la planification de sprint. Cette décision de déplacer ce sujet m’a demandé beaucoup d’efforts, d’autant plus que j’en ai profité pour revoir une grande partie du contenu de l’édition 3, en intégrant des notions nouvelles inspirées du courant #noEstimates.
Bac d'affinage et plan de release

Bac d'affinage et plan de release

Dans une situation où il est nécessaire d’avoir un plan à moyen terme -un plan de release- voilà comment se servir du bac d’affinage. Plan de release, ou pas, c’est la question. Si la réponse est oui, les bacs facilitent grandement son élaboration et son suivi. Pendant le sprint zéro (ou après), on place dans ce bac tout ce qu’on prévoit de faire pour la date de fin de release. Bien sûr il ne s’agit pas de tout décomposer en stories, donc on se retrouvera aussi avec des epics.
Chapitre sept

Chapitre sept

Dans la série Suppléments en ligne de mon livre Scrum, voici la réunion de planification de sprint, qui constitue le chapitre 7. Ce chapitre fait partie de ceux que j’ai réécrits pour l’édition 3. Structure du chapitre Voici le plan de ce chapitre sur la planification de sprint. Le résumé en fin de chapitre La planification du sprint est la première réunion du sprint, celle qui permet à l’équipe de s’engager sur le but du sprint et s’accorder sur les stories associées.

Scrum Guide 2013 et pablotages

Ken Schwaber et Jeff Sutherland, les fondateurs de Scrum, ont mis à jour le Scrum Guide. Pablo en a fait son décodage. Pablo Pernot vient de publier un billet Scrum2013, le canevas, dans lequel il compare ses pratiques avec ce que propose ce nouveau guide. Par un tweet, Pablo m’a demandé ce que j’en pensais. Comme les commentaires de son billet sont fermés, je vais donner ma position ici. Tout d’abord je remarque que comme pour la version précédente (2011), ce guide est publié juste après une version de mon livre[1].

Déroulement de la réunion de planification du sprint

Ma présentation de la réunion de planification du sprint sur ce blog date d’un billet de 2007. Depuis ça a changé. Dans les premières éditions de mon livre, j’avais fait quelques aménagements à cette présentation, en précisant notamment que l’estimation des tâches était optionnelle. Je vais apporter des changements beaucoup plus significatifs dans l’édition 3. Voici comment j’envisage de présenter le déroulement de la réunion : L’équipe se met dans le contexte du sprint, présenté par le Product Owner.

Quizz, la question 6 sur la planification de sprint

La question était la suivante : La vélocité des 2 sprints passés est 13 puis 11. A la fin de la planification de sprint, l’équipe est prête à mettre 20 points dans le sprint. Vous êtes Product Owner, quelle est votre réaction ? C’est un QCM avec 4 choix possibles, comme les questions précédentes. Il fallait choisir parmi les réponses que je proposais[1] : Voyant l’équipe motivée, vous essayez d’ajouter une autre story.
Plan de release, ou pas

Plan de release, ou pas

La nouvelle édition du guide Scrum présente la planification de release comme une pratique en dehors de Scrum : La planification de release est intéressante lorsqu’on pratique Scrum, mais n’est pas exigée par Scrum lui-même. C’est une évolution car dans la version précédente, même si ce n’était pas toujours bien cohérent, la planification de release était présentée comme une pratique Scrum. Faire un plan de release, c’est effectivement souvent utile, notamment quand on a besoin de se synchroniser avec d’autres équipes ou d’autres services de l’organisation.

Garder du mou pendant le sprint

Même si on pense avoir tout prévu, des événements inattendus viennent toujours freiner l’avancement du sprint, en bloquant ou ralentissant une ou plusieurs tâches en cours. Pour empêcher ces événements de remettre en cause l’engagement de l’équipe sur les stories d’un sprint, il faut garder du mou[1] lorsqu’on planifie le sprint. Dans la planification du sprint, le mou, c’est du temps non affecté, qui reste disponible, au cas où. Concrètement le mou est la différence entre les ressources de l’équipe pour le sprint et le temps estimé pour réaliser les tâches connues au moment de la réunion de planification.

Extraits en ligne

Mon livre sur Scrum est sorti depuis le 10 février. L’éditeur est content. Moi aussi. Mon éditeur, Dunod, vient de m’annoncer qu’il y a en a déjà plus de 900 de vendus. Wooooowww ! Parmi les lecteurs de mon blog, il en reste peut-être qui pourraient être intéressés par le livre mais aimeraient lire un extrait avant de se prononcer. Ca tombe bien, Dunod vient de mettre des extraits en ligne sur son site.
Types de tâches

Types de tâches

Cet après-midi, une idée remontée de la rétrospective portait sur l’identification de types de tâches avec des codes de couleur. Pendant le sprint, l’équipe a eu du mal à s’y retrouver dans le tableau des tâches affiché au mur[1] de la salle commune et en particulier pour savoir facilement quelles tâches de développement restaient à faire. La proposition, qui a été retenue pour le sprint suivant, consiste à associer une couleur de post-it aux 3 types de tâches suivants :

Atelier XP Game

L’association SigmaT organise aujourd’hui, en fin d’après-midi, un atelier ludique et éducatif, appelé XP Game. Le nom indique son origine Extreme Programming, mais il est tout a fait indiqué aussi pour ceux qui font du Scrum. Comme le dit Thierry (qui va l’animer en occitan ?), un agiliste doit avoir participé au moins une fois à un XP Game. C’est ouvert à tous.

La capacité corrigée des variations saisonnières

J’avais entendu parler une première fois de coefficient de focalisation en interviewant une équipe il y a quelques mois, sans y prêter une attention particulière. Mais récemment, quand 2 autres équipes Scrum ont évoqué devant moi ce coefficient, je me suis dit que ça venait d’une source unique. Effectivement, dans la traduction française du Scrum and XP from the trenches de Kniberg, on trouve de la focalisation en masse. 30 occurrences !
Le calendrier visuel, un outil de suivi très agile

Le calendrier visuel, un outil de suivi très agile

Rendez le tout visuel

Ce billet est l’œuvre d’un blogueur invité, Bruno Sbille. Bruno écrit régulièrement sur Scrum, les méthodes agiles et le management de projets ; il publie sur son blog Scrum and Agile in Belgium, en français et en anglais. Lors de la dernière release de notre projet j’ai eu à travailler avec une équipe de 7 personnes. Or parmi les membres de l’équipe, personne n’était staffé à 100 % sur le projet.
Plan de release en couleurs

Plan de release en couleurs

avec iceScrum

Un plan de release présente les itérations à venir et le contenu prévu de ces itérations. Ce contenu consiste en des éléments du backlog de produit. Présenté sous forme de tableau, un plan de release est facile à comprendre. Il constitue un outil de communication important avec tous les intervenants du projet. Voici un exemple du plan de release du projet IceScrum. La release apparaît dans le bandeau supérieur, avec ses attributs.

Estimation en points et planification de release

C’est le sujet de ma présentation de vendredi au SigmaT8. Ceux qui ne connaissent pas trop l’agilité pensent parfois, à tort, qu’on ne peut pas planifier sur les projets agiles, parce que ça change tout le temps. Ils ont bien compris que le client pouvait faire des changements. Ils doivent en déduire : A quoi ça sert de faire des plans s’ils sont remis en question ? D’autres qui appliquent l’agilité depuis peu ont compris que dans les méthodes agiles il y avait bien de la gestion de projet et de la planification à court terme (tableau des tâches, burndown chart de sprint), mais ne voient pas encore l’intérêt de la planification de release, à moyen terme.

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.
Répétitions pour les ateliers

Répétitions pour les ateliers

J-2 pour la conférence Agile Tour de Toulouse ! Jeudi lors de la conférence Agile Tour à Toulouse, il y aura, après les exposés et avant le retour d’expérience, 3 sessions en parallèle comme prévu dans le programme. Pour les participants, voici quelques indications pour vous permettre de choisir votre session, sachant qu’il y a des contraintes sur le nombre de personnes pouvant y assister. Nous recueillerons vous souhaits dès l’accueil.