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 ?
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.
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.
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 :
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.
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.
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.
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.
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 :
À quoi ça sert de faire des plans s’ils sont remis en question ?
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.
