Le Sprint Goal, pour moi, c’est l’esprit, l’essence de Scrum. Mais alors pourquoi est-ce souvent si dur de définir un bon Sprint Goal ?
D’abord, c’est quoi un sprint goal ? Voilà ce que dit le Scrum Guide :
L’Objectif de Sprint est l’unique but du Sprint. Bien que l’Objectif de Sprint soit un engagement fait par les Developers, il offre une certaine flexibilité en termes de travail nécessaire pour atteindre cet objectif. L’Objectif de Sprint crée également de la cohérence et du focus, tout en encourageant la Scrum Team à travailler ensemble plutôt que sur des initiatives séparées
Scrum Guide, 2020
C’est donc un élément central de Scrum, qui permet de définir des étapes intermédiaires vers l’objectif du Produit. Le sprint goal constitue pour moi un élément extrêmement important pour que l’équipe puisse comprendre et mettre en œuvre les principes et l’état d’esprit de Scrum.
Par contre, j’ai observé dans de nombreuses équipes des difficultés à fixer des sprints goals en alignement avec l’état d’esprit agile et Scrum. Souvent, le sprint goal va devenir une liste de choses à faire pendant le sprint, sans cohérence, et au final ne sera pas utilisé pour prioriser ou prendre des décisions pendant le sprint.
Pour vous aider dans votre recherche d’un bon sprint goal, j’ai listé quelques problèmes types que j’ai pu identifier au cours de mes expériences, avec à chaque fois des idées de solutions à tester.
❌ Problème identifié = REPARTITION des tâches dans l’équipe
- 🩺 Situation/Symptômes :
- L’équipe ne sait pas travailler à plusieurs sur un même scope, sur un même problème à résoudre, donc chaque membre de l’équipe travaille sur “son” sprint goal et ne travaille pas vraiment en équipe.
- 💡 Idées de solutions à tester :
- Travailler avec l’équipe de développement sur ce qui les bloque pour pouvoir travailler à plusieurs sur un problème : est-ce un problème de découpage des stories? Est-ce qu’on leur demande bien de résoudre en équipe un problème orienté utilisateur et pas juste de dépiler des tâches techniques ? Est-ce qu’ils ont des blocages techniques ?
- On peut suggérer du pair-programming, voire du mob-programming pour pousser tout le monde à travailler ensemble.
- On pourra également creuser le sujet du découpage des stories en tâches, pour essayer de pousser l’équipe à faire travailler toutes les compétences en chevauchement plutôt qu’en séquentiel. L’UX qui fait les maquettes n’attend pas d’avoir tout finalisé pour commencer à travailler avec le dev qui va développer la feature. Le dev qui a développé la feature n’attend pas d’avoir tout finalisé pour travailler avec le QA qui va tester, etc. Ca va amener toute l’équipe à mieux travailler ensemble, à s’aider et se challenger les uns les autres et à rendre la communication plus fluide dans l’équipe.
❌ Problème identifié = Manque de FOCUS
- 🩺 Situation/Symptômes :
- L’équipe se disperse sur beaucoup de sujets différents et ne sait pas ou ne peut pas se concentrer sur ce qui a le plus de valeur au moment présent, donc il est compliqué de définir un sprint goal stable sur un sprint.
- Les priorités ne sont pas claires, tout est très urgent, donc on attaque tous les fronts à la fois.
- L’équipe subit des ingérences externes dans la priorisation, ce qui fait qu’ils ont du mal à se fixer sur un sprint goal cohérent.
- 💡 Idées de solutions à tester :
- Travailler avec le PO sur la priorisation avec des critères de priorisation clairs et transparents pour les parties prenantes et pour l’équipe. Impliquer les parties prenantes dans cette priorisation, les sensibiliser aux problèmes de context switching et de manque de focus de l’équipe.
- Introduire des notions plus agiles de planification, par exemple en utilisant le cône d’incertitude. Les sprints goals sont des points d’étape vers l’atteinte de la vision produit.
- Commencer par définir ce qui à l’intérieur du sprint backlog, doit absolument être livré pour que le sprint soit un succès. Prioriser ces éléments sur le reste en cas de risque de ne pas atteindre le sprint goal.
❌ Problème = Manque de PREDICTIBILITE
- 🩺 Situation/Symptômes :
- L’équipe ne maîtrise pas sa vélocité et ne l’utilise pas en sprint planning pour définir son commitment. Les sprints goals sont rarement atteints parce qu’ils sont trop ambitieux, et l’équipe n’arrive pas à corriger sa vélocité.
- L’équipe veut être ambitieuse et se projette sur beaucoup de choses dans un sprint, parce qu’ils subissent une pression pour livrer vite, mais finissent pas s’essouffler et se décourage à force de ne pas atteindre ses objectifs.
- 💡 Idées de solutions à tester :
- Réduire DRASTIQUEMENT le scope du sprint : ne prendre qu’un seul élément, le livrer (jusqu’à être potentiellement releasable) puis ensuite seulement passer à la suite.
- Utiliser le sprint goal dans tous les daily scrum. Diriger les 3 questions habituelles vers l’atteinte du sprint goal : “qu’est-ce que j’ai fait hier / qu’est-ce que je vais faire aujourd’hui / est-ce que je rencontre des problèmes … POUR RAPPROCHER L’EQUIPE DU SPRINT GOAL “. utiliser le sprint goal pour prioriser les éléments à l’intérieur du sprint backlog et prendre les bonnes décisions.
- Ne pas prendre plus de points que la vélocité moyenne sur les 3 derniers sprints. Rendre cette règle impossible à outrepasser.
❌ Problème identifié = DECOUPAGE des éléments de backlog
- 🩺 Situation/Symptômes :
- Les éléments du backlog ne sont pas correctement découpés et il est donc difficile de faire rentrer ces sujets dans un sprint
- Les éléments de backlog sont des tâches à effectuer et pas des problèmes à résoudre, donc on ne peut pas trouver une cohérence dans un seul sprint goal, on finit avec une liste de choses à faire au lieu d’un sprint goal.
- 💡 Idées de solutions à tester :
- Travailler avec le PO sur un découpage plus vertical des éléments de backlog, en petits morceaux portant chacun une valeur produit, en plus petits problèmes à résoudre plutôt qu’en liste de tâches dépendantes qui n’ont pas de valeur par elle-même (par exemple utiliser les critères INVEST).
- Faire un story mapping pour découper le backlog en petits éléments qui ont du sens et qui s’inscrivent dans un parcours utilisateur complet. Aller finement dans le découpage des éléments les plus prioritaires pour aller potentiellement jusqu’à constituer des releases faisables en un sprint.
❌ Problème identifié = DEPENDANCES et Work In Progress
- 🩺 Situation/Symptômes :
- On a beaucoup de dépendances externes à l’équipe, qui n’est pas autonome sur la livraison de valeur de bout en bout
- Pendant qu’il y a des sujets qui sont “en attente”, l’équipe lance d’autres sujets en parallèle pour que tout le monde soit occupé, ce qui fait exploser le work in progress et ralentit beaucoup la livraison de valeur.
- 💡 Idées de solutions à tester :
- Travailler sur les dépendances pour les réduire et rendre l’équipe la plus autonome possible dans la livraison de valeur de bout en bout. Il y aura toujours des dépendances, mais on doit commencer par réduire tout ce qui peut être réduit.
- Introduire des work in progress limit dans le process de l’équipe et les sensibiliser sur le fait que l’objectif n’est pas que chacun soit occupé à 100% de son temps dans l’équipe mais qu’il est par contre beaucoup plus important d’atteindre le sprint goal en équipe. On considère qu’il est plus important de livrer de la valeur de manière itérative et incrémentale que d’optimiser le temps passé à travailler sur des choses qui ne sont pas forcément prioritaires.
- Engager un travail de fond de réorganisation des équipes et de redesign de l’organisation en utilisant les principes de Team Topologies, la loi de Conway voire la manoeuvre de Conway inversée. Ca ce sera pour un autre article peut-être 😀.
Voilà quelques idées qui peuvent vous mettre sur des pistes de solutions. Chacune de ces idées pourrait faire l’objet d’un article entier (et le fera peut-être!).
En attendant, il n’y a pas de solution miracle, définir un bon sprint goal, en ligne avec l’esprit de Scrum et les valeurs et principes agile, ce n’est pas simple, et ça demande que beaucoup de choses soient assimilées et comprises par l’équipe Scrum.
Donc surtout, ne lâchez pas ce sujet de vue, même si parfois vous devrez faire des compromis et choisir de travailler sur autre chose pour y revenir par la suite !
Si vous vous êtes reconnus dans certaines de ces situations ou symptômes, si voulez discuter de ce sujet, si vous avez besoin d’aide pour creuser des solutions, n’hésitez pas à me contacter !