En tant que Scrum Master, je remarque que Scrum se démocratise de plus en plus ce qui, de mon point de vue, est une bonne chose.

Ces nouvelles mises en pratique de Scrum se basent parfois sur l’expérience de collègues ou sur des articles lus sur Internet. Je constate que peu de personnes prennent le temps de revenir à la source et lire le Scrum Guide, un fascicule de 13 pages qui comme son nom l’indique contient les règles du jeu de Scrum. Du coup, Scrum est appliqué sans forcément comprendre le but derrière certains événements ou certaines responsabilités de l’équipe Scrum (comme celle du Scrum Master de faire comprendre et respecter Scrum).

C’est dans ce contexte que j’ai imaginé l’écriture de cette série d’articles sur les événements Scrum. J’ai le désir ici de réexpliquer les fondamentaux autour des événements, de présenter les améliorations liées à la nouvelle version du Scrum Guide sorti en novembre 2020 et de dézinguer certains mythes autour de Scrum.

Je démarre donc en toute logique cette série par un article sur le Sprint Planning.

But

Inspecter le Product Backlog, l’incrément, les métriques à disposition, la Definition of Done et les améliorations définies durant la rétrospective pour définir un Sprint Backlog.

Qui

La Scrum Team, à savoir les personnes ayant les responsabilités de Developers, de Scrum Master et de Product Owner.

Quand

Au début de chaque sprint, au maximum une séance de travail de 8 h pour un sprint d’un mois.

Pourquoi

Le résultat d’un Sprint Planning permet de répondre à plusieurs questions :

  • Pourquoi ce sprint est-il important ?
  • Que peut-on faire durant ce Sprint ?
  • Comment le travail choisi sera-t-il réalisé ?

Lors d’un Sprint Planning, le Product Owner explique l’axe par lequel il est possible d’ajouter de la valeur au produit. Toute l’équipe crée alors un Objectif de Sprint réaliste. Les Developers sélectionnent les éléments à ajouter au Sprint Backlog et si nécessaire les découpent et les affinent pour avoir une vision plus précise et claire sur le contenu des éléments et comment ils seront concrètement développés.

Au sortir du Sprint Planning, l’équipe aura un Sprint Backlog qui inclut l’Objectif de Sprint, les éléments sélectionnés et un plan pour les livrer.

Le Scrum Guide 2020

En novembre 2020, un nouveau Scrum Guide,  est sorti avec plusieurs améliorations.

Dans le cadre du Sprint Planning, il est intéressant de se pencher sur la notion d’Objectif de Produit. En effet, il est maintenant prévu que le Product Backlog soit composé d’éléments qui permettent d’atteindre un Objectif de Produit. Un Objectif de Produit est un but à moyen terme que le Product Owner désire atteindre avec son produit. Nous aurons donc différentes granularités d’objectifs :

  • L’Objectif de Produit permet de définir ce qui compose le Product Backlog
  • L’Objectif de Sprint permet de définir ce qui compose le Sprint Backlog.

Nous pourrions par exemple avoir pour la société Uber, un Objectif de produit qui est Avoir au moins 1 conducteur pour 50 habitants dans chacun de ces pays au 31 décembre 2021. Pour atteindre cet Objectif de produit, nous aurons plusieurs sprints. L’Objectif de l’un des Sprints pourrait être Rendre le processus de démarrage des conducteurs plus user-friendly ou encore Implémenter la geo-localisation.

Le Scrum Guide 2020 a revu la décomposition du Sprint Planning. En substance, cela est resté la même chose. Cependant un peu plus de clarté a été donné sur la création de l’Objectif de Sprint et sur l’étape importante de se demander “Pourquoi ce sprint est-il important ?”

Mythes

L’Objectif de Sprint, la licorne, le Minotaure, le yéti ou encore le dahu : des animaux mythiques

L’Objectif de Sprint est souvent le mythe par excellence de Scrum ! Je ne vous cacherai pas qu’en tant que Scrum Master, il m’a fallu plusieurs années avant de me persuader que cette bête existait vraiment… et qu’elle avait des vertus incroyables (encore mieux que la corne de licorne).

J’admets également volontiers que l’Objectif de Sprint est l’une des notions les plus compliquées à s’approprier. Souvent, les équipes espèrent trouver l’objectif parfait qui inclura tous les éléments du sprint, mais c’est prendre le problème à l’envers !

Le Product Owner connaît les priorités et il viendra au Sprint Planning avec une proposition de valeur à ajouter au produit. Autour de cela, l’équipe Scrum pourra définir un Objectif de Sprint et choisir les éléments dans le Product Backlog qui permettront de construire cet objectif.

L’objectif initialement proposé est-il trop ambitieux ? L’équipe discute, négocie et arrive à une entente : un objectif qui semble réalisable en un sprint. En sens inverse, il arrivera parfois qu’on ajoute des éléments dans le Sprint Backlog qui ne sont pas directement liés à l’Objectif de Sprint… ça arrive, on essaie d’éviter, mais la réalité est complexe.

Ce qu’il faut éviter par contre, c’est de faire une liste d’Objectifs de Sprint, parce que dans ce cas… autant lister tous les éléments du Sprint Backlog, ce sera plus rapide.

Un Objectif de Sprint va vous permettre d’avoir une vision, un guide pour prendre des décisions, donner une saveur différente à chaque sprint et pouvoir se focaliser sur la valeur. Avoir un Objectif de Sprint permet à l’équipe de se rallier autour d’un objectif commun plutôt que d’avoir chaque individu qui travaille dans son coin pour terminer sa tâche.

L’Objectif de Sprint est un excellent moteur lors du Daily Scrum également : la question qui devrait revenir systématiquement est « Où en est-on par rapport à l’objectif ? Quels choix devons-nous faire en vue de réaliser l’objectif ? Avons-nous un blocage pour atteindre l’objectif ? »

Voici quelques questions qui aident à formuler un Objectif de Sprint :

  • Quelle est la prochaine étape pour atteindre l’Objectif de produit ?
  • Pourquoi réalise-t-on ce sprint ?
  • Comment savons-nous que le sprint est réussi ?
  • Quelles sont les hypothèses et suppositions que nous voulons vérifier ?

Dommage que je n’aie pas le talent pour écrire une ode à l’Objectif de Sprint. Cela donnerait quelque chose comme « Enfant malmené et souvent oublié de Scrum, c’est pourtant lui qui amène l’unité de la famille ».

La toute-puissance du Product Owner

À la lecture du mythe sur l’Objectif de Sprint, vous avez peut-être tiqué en vous disant : « Comment ça, le Product Owner amène une proposition de valeur ? Comment ça, il y a une discussion avec toute l’équipe ? Mais non, voyons. Le Product Owner dit. Les Developers exécutent. »

Si c’est le cas, c’est que vous avez cédé au mythe du Product Owner tout puissant. Vous avez raison : le Product Owner donne la vision et la priorité de ce qui a le plus de valeur. Cependant, c’est bien l’équipe au complet qui va discuter autour de ces priorités sur la faisabilité, les dépendances, les estimations, la compréhension…

D’ailleurs, j’insiste sur le fait qu’il s’agit d’une séance de travail collaborative avec toute l’équipe ! Ce n’est pas le Product Owner qui va dicter le travail qui sera fait et en sens inverse, il ne s’agit pas d’avoir des Technical Leaders qui ont le pouvoir sur toutes les décisions techniques ou encore les Developers qui dictent les priorités.

Quoiqu’il en soit, les Developers ont le dernier mot sur le contenu du sprint, le Product Owner ne peut pas imposer un élément.

Estimation en Story Point sinon rien

Dans le Scrum Guide, il est indiqué que les éléments du backlog peuvent se composer entre autres d’une taille. C’est tout, pas de précision sur la forme que doit prendre cette taille. Si vous voulez utiliser des tailles de t-shirt, des story points, des jours/hommes, des tailles d’animaux… c’est vous qui voyez.

Il est vrai cependant que les Story Points sont souvent appréciés des équipes avec en complément la méthode du Planning Poker. L’estimation relative facilite grandement la discussion et évite d’avoir des discussions sans fin pour savoir si cet élément vaut plutôt 1,5 jour ou 1,25 jour.

Méfions-nous quand même de la mise en œuvre de cette pratique qui reste parfois incomprise et qui peut amener des dérives sur la notion de Vélocité. Enfin, tout cela mériterait bien un article en soi…

Conclusion

J’espère que cette remise en contexte du Sprint Planning vous permettra de mieux comprendre ce qui vient de Scrum et ce qui est une adaptation liée à votre contexte ou peut-être à une mauvaise compréhension du Scrum Guide.

J’aimerais cependant souligner ici que les adaptations ne sont pas forcément mauvaises. L’important est de faire ces changements en pleine conscience et de comprendre ce que cela apporterait de le faire “selon la théorie”.

Retrouvez la suite des articles de la série :

Sabrina Ferlisi

Scrum Master et Coach Agile à Pyxis Suisse.

En 2014, après un master d’ingénieur en informatique et des années dans le développement logiciel et la gestion de projet, Sabrina tombe dans la marmite de l’Agilité en tant que Scrum Master et découvre un nouveau monde. Depuis, elle est passionnée par tout ce qui touche aux interactions humaines, à la communication et à l’amélioration continue.

Énergique, intuitive et organisée, elle met son savoir-faire au service des équipes et des organisations en donnant à la fois un cadre et de la souplesse aux environnements complexes.

Sabrina est également Scrum Trainer, et donne les formations Professional Scrum Master (formation certifiante de scrum.org).

Billet précédent

#5 - Julien Duvanel - être un manager "servant leader" pour mes équipes

Billet suivant

Gestion, sentiment de sécurité psychologique et changement durable

Pas de commentaire

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.