Planification de Sprint orientée engagement
Il existe deux façons fondamentales de planifier un Sprint :
1) Le Sprint Planning orienté vélocité
(en tenant compte de la charge de travail moyenne d'une équipe), et
2) Le Sprint Planning orienté engagement
(en tenant compte de ce qu'une équipe pense pouvoir accomplir lors d'un Sprint)
J'ai déjà expliqué le Sprint Planning orienté vélocité, concentrons-nous donc ici sur le Sprint Planning orienté engagement :
Les réunions de Sprint Planning orientées engagement impliquent le Product Owner, le ScrumMaster et toute l'équipe de développement. Le Product Owner donne un aperçu des Product Backlog Items ayant la priorité la plus élevée et les explique ensuite à l'équipe.
Sélectionner un élément
Ensuite, les membres de l'équipe sélectionnent un item pour le prochain Sprint. Dans la plupart des cas, il correspond à l'item auquel le Product Owner a accordé la priorité la plus élevée. Cependant, il peut arriver que l'item du Product Owner comporte encore trop de points non clarifiés.
Idéalement, l'équipe devrait tout de même être en mesure d'intégrer cet item dans le Sprint et de clarifier les questions ouvertes suffisamment tôt pour pouvoir tout de même le terminer. Toutefois, s'il y a trop de points à résoudre, s'ils sont trop complexes ou trop chronophages, alors l'item sélectionné par le Product Owner devrait être mis de côté pour le moment.
Tâches et heures
Une fois qu'un item a été sélectionné, les membres de l'équipe discutent du travail associé et identifient les tasks (tâches) nécessaires pour pouvoir livrer le Product Backlog Item. Pendant ce temps ou juste après, l'équipe estime le temps (en heures) dont elle aura approximativement besoin pour chaque task.
Mais ne vous attendez pas à ce que l'équipe donne une estimation pour chaque task. Ce n'est pas seulement impossible, mais aussi inutile.
Les membres de l'équipe devraient simplement estimer suffisamment de tasks pour avoir le sentiment d'avoir bien réfléchi à l'ensemble. Car c'est le véritable objectif d'une telle réunion. Définir les tasks et le nombre d'heures est secondaire.
La question des engagements
Une fois que les membres de l'équipe ont défini les tâches et peuvent estimer approximativement le temps nécessaire pour certains éléments du backlog, ils devraient se poser la question : "Pouvons-nous nous engager sur cela ?"
Je trouve important que l'équipe se pose elle-même cette question et que ce ne soit pas le Scrum Master qui demande : "Pouvez-vous vous engager sur cela ?" Car ainsi, ils s'engagent les uns envers les autres, plutôt qu'envers le Scrum Master.
Je ne sais pas comment c'était pour toi, mais mes premières années dans la vie professionnelle (à l'époque avant Scrum) étaient marquées par des engagements impossibles à tenir envers des supérieurs qui demandaient certes "Pouvez-vous y arriver ?", mais voulaient en réalité dire "Débrouillez-vous pour y arriver !"
Même si le Scrum Master est désigné comme "Master", il n'est pas un supérieur de l'équipe et ne devrait pas non plus donner cette impression. Il vaut mieux ne pas être perçu comme un chef qui insiste sur le respect de tous les engagements.
Au lieu de cela, une équipe devrait être amenée à se demander elle-même : "Pouvons-nous nous engager ?" Car un engagement est beaucoup plus fort lorsque l'équipe s'engage envers elle-même.
De plus, il est clair que la question de l'équipe "Pouvons-nous nous engager ?" ne peut avoir que deux réponses possibles, à savoir "Oui, nous le pouvons" ou "Non, nous ne le pouvons pas." En revanche, si le Scrum Master demande "Pouvez-vous vous engager ?", certains membres de l'équipe répondront par "nous" et d'autres par "je".
Scrum exige un engagement de toute l'équipe : "Si tu as besoin d'aide, je t'aiderai et je sais que tu ferais la même chose pour moi." et non "Ceci sont mes tâches et cela sont les tiennes."
Répéter le processus pour les autres stories
Si l'équipe convient qu'elle ne peut pas s'engager sur un élément particulier du Product Backlog, elle choisit un autre élément et répète le processus – tâches, heures, engagement – jusqu'à ce que quelqu'un dise qu'il ne peut pas s'engager sur l'élément sélectionné.
Dans ce cas, les membres de l'équipe discutent de la situation et vérifient si quelqu'un d'autre peut les aider. Peut-être qu'un administrateur de base de données ayant des connaissances rudimentaires en JavaScript peut aider un développeur JavaScript débordé.
Si ce n'est pas le cas, la story peut être remise dans le backlog et un élément plus petit ou plus simple peut être sélectionné, sur lequel tout le monde peut s'engager.
Qu'en est-il des Story Points et de la Velocity ?
Vous avez peut-être remarqué que ni les Story Points ni la vélocité n'ont joué de rôle jusqu'à présent dans ce processus. Je recommande toujours d'estimer les éléments du Product Backlog à l'aide de Story Points. Cependant, les Story Points et la vélocité ne jouent pas vraiment de rôle jusqu'à ce stade du Sprint Planning orienté engagement. En revanche, ils jouent un rôle important dans la dernière phase d'une réunion de Sprint Planning.
Vérification de la plausibilité des engagements
Une fois que l'équipe a rempli le temps disponible dans un Sprint, le Scrum Master peut vérifier combien de Story Points les différents items avaient reçus auparavant. Il communique ensuite ce résultat à l'équipe. L'équipe peut alors comparer ce chiffre avec sa Velocity moyenne ou actuelle.
Supposons qu'une équipe avec une Velocity moyenne de 20 organise une telle réunion de Sprint Planning et sélectionne des items totalisant 19 Story Points. Elle a choisi ces items sans savoir combien de Story Points leur avaient été attribués auparavant.
Lorsque le Scrum Master leur annonce qu'ils viennent de sélectionner des items totalisant 19 Points et que leur Velocity moyenne est identique ou très similaire, les membres de l'équipe peuvent en déduire qu'ils ont planifié la bonne quantité de travail pour le Sprint.
Cependant, si seulement des items totalisant 11 Story Points ont été sélectionnés, ils devraient se demander pourquoi ils considèrent maintenant ce travail comme beaucoup plus difficile.
Cela pourrait par exemple s'expliquer par le fait qu'au cours du Sprint Planning, ils ont identifié du travail qu'ils n'avaient pas pris en compte auparavant. Ou bien ils constatent simplement qu'une Story est en réalité plus compliquée que prévu.
Dans tous les cas, l'équipe saura si elle a choisi une quantité de travail appropriée ou si elle peut peut-être en prévoir davantage.
D'un autre côté, les membres de l'équipe se demanderont ce qu'ils n'ont pas pris en compte s'ils ont sélectionné des items totalisant 30 Points – soit 10 de plus que leur moyenne. La question pourrait alors être : "Pourquoi ce travail semble-t-il tellement plus simple après le Sprint Planning qu'avant ?"
La Velocity et les Story Points ne jouent donc aucun rôle pendant la majeure partie d'un Sprint Planning orienté engagement. Ils sont cependant indispensables lorsqu'il s'agit de vérifier et de confirmer la planification.
Un engagement n'est pas une garantie
Il est important de ne jamais considérer un engagement comme une garantie. Comme Clint Eastwood l'a dit dans un de ses films : "Si tu veux une garantie, achète-toi un grille-pain !"
L'engagement d'une équipe signifie que tout le monde donne le meilleur de soi-même. Si elle peut tenir ses engagements dans 80 pour cent des cas, c'est une bonne moyenne. Cela signifie aussi qu'elle doit prendre les choses au sérieux et utiliser le temps de manière optimale. Cela crée la confiance dans l'équipe et dans ce qu'elle affirme pouvoir accomplir.
Cependant, l'objectif ne devrait pas être de toujours tout terminer à 100 pour cent. Une équipe forcée de toujours tout terminer y parviendra certes – mais seulement en fixant ses engagements à un niveau plus bas.
J'ai appelé cette approche "Sprint Planning orienté engagement". Elle est aussi désignée sous le terme de "Planification basée sur la capacité". Ce terme me plaît de plus en plus, car un engagement peut trop facilement être compris comme une garantie.
Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en français.
