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

Sprint planning

La planification du sprint (en anglais Sprint Planning) est un rite 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. Voyez les activités qu’on y mène avec la mindmap. 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

Plan de release ou pas ?

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

Ce chapitre fait partie de ceux que j’ai réécrits pour l’édition 3. La mindmap montre sa structuration. 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. C’est aussi la plus délicate : son bon déroulement conditionne le succès du sprint. Pour la réussir, il convient de ne pas la voir uniquement comme une séance de planification, mais aussi comme un exercice collectif pendant lequel l’équipe apprend à s’auto-organiser et à partager la connaissance sur le produit et sur la solution pour le développer.

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

Ce rite a évolué depuis le début de Scrum

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

À vous de voir

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

Associer une couleur de post-it aux 3 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

C'est facile 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.