Que se passe-t-il dans un Sprint et à quel moment ?
La mise en œuvre réussie de Scrum comprend une série de cérémonies importantes. Parmi celles-ci, on trouve le Sprint Planning, le Sprint Review, le Daily Scrum, la Sprint Retrospective et bien d'autres.
Il existe souvent des incertitudes sur qui devrait participer à quelles cérémonies Scrum, quand elles ont lieu, combien de temps elles devraient durer, quel est l'objectif de chaque cérémonie, etc.
Dans cet article, nous allons tenter de clarifier ces points :
Le Sprint Planning
Lorsque le Sprint commence, le Sprint Planning est également réalisé. Il marque donc officiellement le début du Sprint.
Toute l'équipe Scrum participe au Sprint Planning ; c'est-à-dire l'équipe de développement ainsi que le Scrum Master et le Product Owner. D'autres personnes peuvent également participer à cet événement dans de rares cas, si le Product Owner et l'équipe de développement le jugent approprié. Par exemple, si une fonctionnalité doit être développée lors du prochain Sprint et qu'elle est mieux expliquée par un expert métier (qui n'est pas le Product Owner), il peut être utile que cette personne soit présente au Planning. Dans la plupart des cas, cependant, il est plus judicieux de mener ces discussions en dehors de la réunion de Planning proprement dite.
La durée du Sprint Planning est proportionnelle à la durée du Sprint. Pour un Sprint de quatre semaines, le Planning ne devrait pas durer plus de huit heures ; pour un Sprint d'une semaine, pas plus de deux heures – soit max. deux heures par semaine de Sprint.
Cette limitation à une durée maximale d'une réunion s'appelle aussi le Time Boxing. Je recommande aux équipes de terminer le Sprint Planning en environ la moitié de la Time Box maximale autorisée.
Comme input pour le Sprint Planning, le Scrum Master apporte des informations sur la Velocity (vitesse de travail) moyenne et actuelle. Le Product Owner apporte le Product Backlog ou au moins les items du Backlog avec la priorité la plus élevée. Dans certaines équipes, le Product Owner propose également un objectif de Sprint préliminaire lors du Planning, qui peut ensuite être retravaillé ensemble avec l'équipe pendant le Planning.
Le résultat du Sprint Planning est une équipe mieux informée et mieux préparée pour les travaux à venir. Les autres résultats du Planning sont le Sprint Backlog et un objectif de Sprint élaboré ensemble.
Daily Scrum / Daily Standup
Le Daily Scrum – également appelé Daily Standup – est une courte cérémonie qui a lieu quotidiennement et durant laquelle les membres de l'équipe se synchronisent sur leur travail. Les Daily Scrums permettent de s'assurer que les bonnes personnes travaillent sur les bonnes choses au bon moment.
Chaque jour, chaque membre de l'équipe répond aux trois questions suivantes :
Qu'ai-je fait hier pour atteindre l'objectif du Sprint ?
Que vais-je faire aujourd'hui pour atteindre l'objectif du Sprint ?
Ai-je des obstacles/problèmes qui m'en empêchent, et si oui, lesquels ?
Ces questions peuvent être formulées de différentes manières. Certaines équipes préfèrent par exemple décrire ce qu'elles ont accompli plutôt que ce qu'elles ont fait.
Les participants devraient être le ScrumMaster, l'équipe de développement, et à mon avis également le Product Owner.
Dans la communauté Scrum, il y a des discussions pour savoir si le Product Owner devrait participer au Daily Scrum ou non. Permettre au Product Owner de ne pas participer au Daily Standup peut trop l'éloigner de l'équipe. Un sentiment de « nous contre les autres » existe déjà dans trop d'organisations. Je ne vois pas pourquoi une équipe Scrum ou son Product Owner voudrait renforcer davantage cette attitude négative.
Les Daily Scrums sont limités à une durée maximale de 15 minutes. L'objectif du Daily Scrum est une brève synchronisation de l'équipe. Contrairement au Sprint Planning, je ne recommande pas ici de terminer en la moitié du temps prévu. Pour la plupart des équipes, 5 à 7 minutes ne suffisent tout simplement pas pour aborder de vrais problèmes ou comprendre quels travaux ont été accomplis. Si les Daily Scrums sont trop raccourcis, ils deviennent rapidement une routine avec des déclarations comme « Hier j'ai fait XY. Aujourd'hui je fais ceci et cela. Je n'ai pas d'impediments. »
Il n'y a pas de résultats formels des Daily Scrums, à part une meilleure coordination des travaux au sein de l'équipe de développement.
Revue de Sprint
La Sprint Review a lieu le dernier jour du Sprint. Le Product Owner, le ScrumMaster et l'équipe de développement doivent être présents, ainsi que les Stakeholders concernés. Les Stakeholders qui doivent participer varient d'un Sprint à l'autre et dépendent de ce qui a été livré pendant le Sprint.
La Sprint Review a une Time Box de maximum quatre heures pour un Sprint de quatre semaines. Les Time Boxes sont proportionnellement plus courtes pour des Sprints plus courts, par exemple une heure pour un Sprint d'une semaine.
Lors de la Sprint Review, tous les Product Backlog Items qui répondent à la Definition of Done doivent être présentés. Cela signifie qu'aucun travail encore en cours, donc pas encore terminé, ne doit être montré. Bien sûr, il peut parfois être judicieux de faire une exception à cette règle.
La démonstration des fonctionnalités terminées est l'activité centrale d'une Sprint Review Meeting typique. Cependant, la plupart des équipes prennent également le temps de discuter des avancées et des éventuels problèmes.
L'objectif de la Review Meeting est de recueillir du feedback sur ce qui a été développé pendant le Sprint. Le Product Owner recueille tous les retours et peut, si nécessaire, ajuster le Product Backlog en fonction de ce feedback. Le résultat d'une Sprint Review est donc un Product Backlog révisé.
Rétrospective de Sprint
Lors de la Sprint Retrospective les membres de l'équipe ont l'occasion de réfléchir à comment améliorer leur façon de travailler. Cela peut par exemple signifier qu'ils souhaitent modifier leur manière d'appliquer Scrum et ajuster la durée du Sprint. La rétrospective peut aussi couvrir des aspects généraux de la collaboration, comme ne plus planifier de réunions le matin ou définir quels sujets peuvent être discutés sur Slack et lesquels devraient être abordés lors d'une conversation en personne.
L'ensemble de l'équipe devrait participer à la Sprint Retrospective – c'est-à-dire l'équipe de développement, le ScrumMaster et le Product Owner. Toute autre approche ne ferait que créer une division au sein de l'équipe. Une bonne équipe agile devrait éviter tout comportement menant à une mentalité « nous contre les autres ».
Hormis la volonté de s'améliorer, la Sprint Retrospective ne nécessite aucun autre input. Le résultat de la rétrospective devrait être une liste de changements ou de propositions d'amélioration que l'équipe souhaite mettre en œuvre.
La timebox pour une rétrospective est de max. 3 heures. De temps en temps, elle peut durer un peu plus longtemps, mais dans la plupart des cas, les équipes terminent en moins d'une heure.
Raffinement du Product Backlog
Le Product Backlog Refinement a pour but de s'assurer que les items en haut du backlog sont prêts pour le prochain Sprint. Cela peut signifier ajouter des détails aux items existants, faire des estimations, supprimer certains items, réorganiser les priorités, découper des items du backlog en items plus petits ou créer de nouveaux items.
Même si le refinement du backlog est nécessaire en soi, cela ne veut pas dire qu'une équipe doit le faire sous forme de cérémonie officielle ou que cela doit être fait à chaque Sprint. La plupart des équipes organisent cependant régulièrement des réunions de Backlog Refinement, généralement une fois par Sprint ou par semaine.
Une bonne règle est qu'une équipe ne devrait pas consacrer plus de 10% de son temps total disponible au Backlog Refinement – que ce soit pendant la réunion elle-même ou lors des discussions ultérieures qui en découlent.
Dans la plupart des équipes, tous les membres de l'équipe de développement ainsi que le Product Owner et le ScrumMaster participent aux réunions. À moins qu'une équipe n'estime les Product Backlog Items lors de ses réunions de refinement, je pense que la moitié à deux tiers de l'effort de développement suffit et que la réunion peut ainsi être la plus courte possible pour l'équipe.
La seule chose à apporter au refinement, ce sont les items en haut du Product Backlog. Les résultats du refinement sont des Product Backlog Items plus petits, mieux adaptés au prochain Sprint, ainsi qu'une meilleure compréhension de certains Product Backlog Items.
Évaluation du Backlog
Comme mentionné plus haut, de nombreuses équipes estiment déjà leurs Product Backlog Items pendant le Refinement Meeting . C'est l'idéal et si possible, toute l'équipe de développement participe au Backlog Refinement.
Si seulement une partie de l'équipe participe au Refinement, les membres de l'équipe se réunissent une fois par Sprint pour estimer tous les nouveaux travaux pour lesquels le Product Owner a besoin d'une estimation.
Pour la plupart des équipes, ces réunions d'estimation doivent rester très courtes . En effet, les équipes ne devraient ni créer trop de nouveaux Product Backlog Items, ni recevoir un flot de nouveaux items de l'extérieur. Les travaux à estimer devraient être soit très importants, soit de nouveaux items ou des items existants qui ont été découpés pour mieux s'intégrer dans le Sprint à venir.
J'aime réaliser le Product Backlog Estimating directement après un Daily Scrum et quelques jours avant la fin du Sprint . C'est suffisamment tard pour que la plupart des nouveaux items aient déjà été identifiés, et suffisamment tôt pour que le Product Owner puisse ajuster la priorisation en fonction des nouvelles informations issues des estimations.
Je ne recommande pas d'estimer les items pendant le Sprint Planning. À ce moment-là, il est trop tard pour que le Product Owner ajuste la priorisation en fonction des estimations. Cela amène également les membres de l'équipe à passer plus de temps sur les estimations qu'ils ne le devraient. Donc, ne pas réaliser l'estimation des Product Backlog Items pendant le Sprint Planning.
Priorisation
Avant le début d'un nouveau Sprint, le Product Owner s'assure que tous les items en haut du Product Backlog ont été priorisés. Selon le dictionnaire Oxford, prioriser signifie : « Classer des tâches, des problèmes, etc. par ordre d'importance afin de pouvoir traiter les plus importants en premier. »
Cela signifie qu'il ne suffit pas de dire : « Tout est nécessaire. » Ou comme un Product Owner m'a dit un jour : « Ce n'est pas pour rien qu'on les appelle des exigences ; c'est parce qu'elles sont requises. »
Dans la plupart des cas, il n'y aura pas de cérémonie officielle pour la priorisation. C'est plutôt quelque chose que le Product Owner fait seul, après avoir échangé avec les parties prenantes pour clarifier leurs besoins et attentes.
La priorisation devrait avoir lieu le plus tard possible dans le Sprint, mais doit absolument être terminée avant le Sprint suivant. Cela signifie souvent qu'elle est effectuée l'un des deux derniers jours du Sprint.
La priorisation n'est généralement pas particulièrement chronophage, car le Product Owner effectue typiquement les ajustements au fil du Sprint en fonction des nouvelles informations, plutôt que de prioriser l'ensemble du backlog dans les moindres détails dès le départ.
Les réunions dans un Sprint
Comme tu peux le constater, il existe un certain nombre de cérémonies importantes dans Scrum qu'il convient de mener avec soin. Nous espérons que cet article t'a permis d'avoir une meilleure vue d'ensemble et t'a apporté plus de clarté dans ton quotidien avec ton équipe Scrum. Si tu souhaites en savoir plus, nos formations Scrum sont exactement ce qu'il te faut.
Cet article provient du blog de Mike Cohn et a été traduit par nos soins.
