Il existe principalement deux manières de faire la planification d’un sprint : la planification de sprint pilotée par la vélocité et la planification de sprint pilotée par l’engagement. Dans un précédent article, j’ai décrit la planification basée sur la vélocité ; dans le présent article, nous allons porté notre attention sur la planification de sprint pilotée par l’engagement.

Une réunion de planification de sprint pilotée par l’engagement nécessite la participation du product owner, du ScrumMaster et de toutes les personnes de l’équipe de développement. Le product owner vient à la réunion avec les items en haut de l’ordre des priorités du product backlog et les décrits à l’équipe, en commençant généralement par une présentation globale de ces items.

Sélection d’un item

Après ça, les membres de l’équipes sélectionne un premier item à prendre en charge dans le sprint. Il s’agira presque toujours de l’item en top priorité pour le product owner, et il est tout à fait possible que cet item contienne toujours de trop nombreux points restant en suspens.

Idéalement, une équipe devrait être capable de prendre en charge cet item pour ce sprint et résoudre ces différents points suffisamment tôt dans le sprint pour pouvoir le terminer. Mais, il est tout à fait possible qu’il y ait trop de points à voir, que ces points soient si importants, ou que la résolution des ces points prennent tellement de temps (par exemple en nécessitant l’organisation d’une réunion avec 25 représentants des utilisateurs) que cet item en top priorité pour le product owner passe à la trappe.

Tâches et heures

Maintenant que l’item prioritaire a été sélectionné, les membres de l’équipe discutent du travail que cela implique, et identifient les tâches qui seront nécessaires pour livrer cet item. Que ce soit parallèlement à l’identification des tâches ou juste après avoir fini de le faire, les membres de l’équipe estiment grossièrement le nombre d’heures que chaque tâche prendra.

Ne demandez pas ou n’attendez de l’équipe qu’elle pense à toutes les tâches possibles qui pourraient être faites pendant le sprint. Non seulement cela est impossible, mais c’est également inutile.

Afin de pouvoir saisir le travail à mener, l’équipe devrait réfléchir à suffisamment de tâches à faire dans le cadre de ce travail - il est important ici de réaliser que cette réflexion sur le travail à mener est bien le véritable objectif de cette réunion. Identifier les tâches et estimer le nombre d’heures est seulement un objectif secondaire.

Demander l’engagement

Après avoir identifié les tâches et estimé grosso modo les heures pour cet item du product backlog, les membres de l’équipe se posent alors la question : “Est-ce que nous pouvons nous engager à le faire ?”.

Je trouve que c’est très important que les membres de l’équipe se posent la question collectivement plutôt qu’avoir un ScrumMaster qui pose une question du type “Pouvez-vous vous engager à le faire ?”. Lorsque les membres de l’équipe se pose la question “Pouvons-nous engager à le faire ?” ils s’engagent les uns envers les autres plutôt qu’envers le ScrumMaster.

Je ne sais pas pour vous, mais au début, ma carrière pré-Scrum a été remplie “d’engagements” non respectés envers les chefs qui me demandaient si j’étais capable de livrer quelque chose en me faisant bien comprendre qu’il valait mieux que ma réponse soit un oui.

Un ScrumMaster n’est pas celui qui commande, il ne devrait pas inspirer des sentiments de ce genre dans l’équipe, mais dans ScrumMaster il y a master, et vaut mieux de ne pas prendre le risque d’être perçu comme un chef qui insiste pour avoir un engagement.

Aider une équipe à se poser la question “Pouvons-nous engager à le faire ?” et il est certain qu’ils s’engageront les uns envers les autres, ce qui devrait avoir pour effet d’avoir un engagement plus fort.

De plus, en ayant une équipe qui se pose la question “Pouvons nous engager à le faire”, il est clair que la réponse devrait être “Oui, nous pouvons” ou “Non, nous ne pouvons pas”. Lorsqu’un ScrumMaster pose la question “Pouvez-vous vous engager ?” certains membres de l’équipe répondront correctement avec un “nous” alors que d’autres répondront avec un “je”.

Scrum demande un engagement complet de la part de l’équipe : si tu as des difficultés ou que tu es à la traine, je te donnerai un coup de main et je sais que tu feras la même chose pour moi. Ce n’est pas “ça, c’est mes tâches” et “celles-là, ce sont les tiennes”.

Et c’est repartit pour un tour avec davantage de stories

Si l’équipe est d’accord sur le fait qu’elle peut s’engager sur un item du product backlog, elle sélectionne un nouvel item et répète à nouveau le processus. Et ainsi de suite - tâches, heures et engagement jusqu’à ce que quelqu’un dise qu’il n’est pas possible s’engager sur l’item qui vient d’être sélectionné.

Si quelqu’un ne peut pas s’engager, les membres de l’équipe discuteront généralement de la situation et chercheront si quelqu’un d’autre est disponible pour filer un coup de main - peut être un administrateur de bases de données avec des compétences de base en javascript pourra aider un développeur javascript qui est débordé.

Dans le cas contraire, cette story peut être éventuellement remise dans le product backlog et qu’un autre item plus petit peut être pris à la place, ou qu’un autre item nécessitant moins de compétences de la part de cette personne pourra être pris.

Pas de points de story ou de vélocité ?

Vous avez peut être remarqué que dans le processus jusqu’à présent, il n’a pas été questions de points de story ou de vélocité. Même si je continue à recommander à que soit donné aux items du product backlog des estimations en points de story rapides et à grosses mailles, ni les points de story ni la vélocité ne jouent un rôle dans la planification de sprint piloté par l’engagement décrit jusqu’à présent.

Toutefois, ils jouent un rôle important dans la dernière étape de la réunion de planification de sprint.

Est-ce que l’équipe fait bien de s’engager ?

Une fois que les membres de l’équipe ont rempli le sprint, le ScrumMaster peut jeter un coup d’œil aux items sélectionnés du product backlog, faire la somme de l’ensemble des points de story attribué sur chaque item, puis communiquer le résultat à l’équipe. Les membres de l’équipe peuvent alors le comparer avec la vélocité moyenne ou avec leur vélocité la plus récente.

Supposons par exemple, qu’une équipe, ayant une vélocité moyenne de 20, s’engage lors d’une réunion de planification de sprint pilotée par l’engagement et prenne pour un total de 19 points de travail. L’équipe s’est engagée sans avoir connaissance des points de story des items du product backlog sélectionnés.

Si leur ScrumMaster leur dit qu’ils ont simplement pris pour 19 points de travail et qu’ils ont une vélocité moyenne de 19, cette équipe devrait se sentir très confiante dans le fait d’avoir sélectionner une quantité de travail appropriée pour ce sprint.

Cependant, supposons à la place que le ScrumMaster de cette équipe lui annonce qu’elle n’a pris que pour 11 points de travail. Les membres de l’équipe pourraient alors se poser la question de savoir pourquoi elle a pu jaugé le travail plus difficile pendant la réunion de planification qu’au moment où elle avait estimé ces mêmes items.

Cela peut révéler, par exemple, que durant la planification de sprint elle a identifié du travail à faire auquel elle n’avait pas pensé avant, ou peut être les membres de l’équipe ont-ils explicitement fait la supposition que ce travail ne ferait pas partie d’une story en particulier. Ou peut être ont-ils découvert que la story était bien plus difficile qu’ils ne le pensaient lorsqu’ils lui ont attribué des points de story.

D’une manière ou d’une autre, sachant qu’ils ont sélectionnés 11 items sur 20 environ, cela peut aider l’équipe de savoir qu’ils ont sélectionnés une quantité de travail appropriée ou d’avoir éventuellement l’occasion d’en prendre davantage.

De manière similaire, si le ScrumMaster annonce que l’équipe a pris du travail à faire pour 30 points, soit 10 points de plus que leur vélocité moyenne, l’équipe peut s’interroger sur ce qu’elle a pu oublier de prendre en considération. “Pourquoi ce travail semble si facile après la planification de sprint qu’il ne l’a été pendant l’estimation en points de story ?”

Donc : les points de story et la vélocité ne jouent aucun rôle dans la majeure partie de la réunion de planification de sprint pilotée par l’engagement. Mais ils jouent un rôle vitale pour vérifier le bon sens du planning et le confirmer.

C’est un engagement, non une garantie.

Il est important que l’engagement de l’équipe ne soit pas compris comme étant une garantie. Comme a pu le dire Clint Eastwood dans un de ses films “Si vous voulez une garantie, achetez un grille-pain”.

L’engagement que prend l’équipe, c’est de faire de son mieux. J’ai le plaisir de voir que souvent leur engagement est tenu dans 80% des cas. Cela doit être quelque chose qu’ils devraient prendre très au sérieux et cela sera sans doute le cas la plupart du temps. C’est nécessaire pour que le métier ait confiance dans la parole de l’équipe lorsqu’elle dit qu’elle peut livrer.

Toutefois, finir tout ce qu’ils ont dit qu’ils feraient 100% du temps ne devrait pas être l’objectif. Une équipe forcée de tout finir tout le temps le fera - mais en réduisant ce sur quoi elle s’est engagée.

À l’origine dans mon livre Agile Estimating and Planning, j’avais appelé cette approche la planification de sprint pilotée par l’engagement ; d’autres l’appellent “planification basée sur la capacité”. J’avoue que je commence à préférer cette dernière appellation car c’est chose trop facile que de transformer par la force l’engagement en garantie.


Auteur : Mike Cohn
Source : Commitment-Driven Sprint Planning
Date de parution originale : 28 Octobre 2014


Traducteur : Nicolas Mereaux
Date de traduction : 09/11/2016


Copyright ©1998-2016 Mountain Goat Software. All Rights Reserved.