De l’idée au Sprint Planning : petit guide du facilitateur

Dans beaucoup d’équipes pratiquant Scrum, la question de la préparation des User Stories en amont de la planification d’itération, ou Sprint Planning en anglais, est cruciale. Ce point de détail sur lequel le Scrum Guide n’apporte aucun conseil, est souvent une vraie difficulté que les équipes ne savent pas comment adresser.

Notre équipe a rencontré ces mêmes problèmes et a trouvé sa solution. Cette approche nous a permis :

• De s’assurer que les pré-requis de l’itération sont bien remplis avant de la démarrer, à savoir :
  • Les User Stories sont « prêtes » (quoi que cela puisse dire)
  • L’équipe est capable de les décliner en tâches techniques
• D’ainsi pouvoir mener un Sprint Planning efficace
• D’une manière générale de réussir à cadrer les réunions préparatoires qui construisent le backlog, notamment les refinements, afin de rester concentré sur l’essentiel et d’être efficace

Finalement, nous sommes même allés plus loin en formalisant cette solution via un document à imprimer, un petit cahier qui sert au quotidien.

La suite de l’article décrit le document dans le détail. Vous pouvez également directement sauter au lien vers le PDF.

Cet article formalise et partage le mode de fonctionnement de notre équipe. Loin de nous de suggérer l’idée que ce soit la seule, ni la meilleure manière de faire. Comme toujours, en fonction de votre contexte, de votre projet, de votre organisation, de votre équipe, la meilleure solution vous est unique. En guise d’ouverture, la fin de l’article évoque justement d’autres pistes.

La petite histoire

Cette histoire se déroule au sein de l’équipe Player à La Direction du Numérique de France Télévisions.

Nous avions un problème récurrent : des refinements nécessaires et fréquents, mais quasi-systématiquement douloureux. Equipe qui s’éloigne des considérations métier, PO perdu face à des échanges très techniques, difficulté à chiffrer des sujets qui ne sont pas bien définis ni fonctionnellement ni techniquement…

Pour y remédier, j’ai proposé de nous recentrer sur l’essentiel du refinement : le pourquoi et pas le comment. C’est souvent cet état d’esprit qui permet de chiffrer les sujets rapidement et efficacement, plutôt que de perdre du temps à tout estimer dans le détail. Oui c’est une perte de temps, car il ne s’agit que d’une estimation : estimer une tâche a moins de valeur que l’effectuer.

Un autre problème s’est posé : si on ne parle pas de technique pendant les refinements, quand l’aborde-t-on ? Quand prend-t-on le temps d’esquisser l’architecture logicielle de la nouvelle fonctionnalité ? Quand spécifie-t-on l’API à implanter ? Ayant déjà travaillé dans le passé avec des clients qui utilisent des « spec » et autres cahiers des charges, la réponse me semblait évidente : l’équipe doit systématiquement prendre du temps sur l’itération courante pour préparer l’itération suivante. Un mot d’ordre qu’on pourrait résumer en : « Mieux vaut bien démarrer l’itération suivante que bien terminer la courante. » Oui mais voilà : nous ne travaillons pas avec des spécifications rigides et connues longtemps à l’avance, et notre backlog change souvent. (et tant mieux !)

Ce qui m’a fait réaliser que l’équipe n’avait pas forcément une vision à court et moyen terme des sujets à venir, ce qui ne facilitait pas leur organisation pour préparer les sujets de l’itération suivante. A donc semblé logique d’instaurer un point en milieu d’itération qui fait un point sur la roadmap et surtout qui annonce les sujets de l’itération suivante, pour s’assurer que l’équipe puisse les préparer avant le début d’itération.

Lorsqu’un nouveau membre rejoignait l’équipe, j’avais pris l’habitude de lui faire un dessin pour expliquer comment nous allions procéder pour préparer les sujets de l’itération suivante. J’ai fini par mettre au propre ce dessin :

L’idée est de matérialiser les évènements clés de notre équipe qui se déroulent en amont de l’itération.

On peut lire ce diagramme dans les deux sens. Commençons par la lecture qui remonte le temps, qui explique bien la raison d’être de cette organisation :

1. Avant de pouvoir démarrer l’itération avec le Sprint Planning, les sujets nécessitent parfois des investigations techniques. Sans ces dernières, l’équipe ne sait pas toujours comment elle devra procéder.
2. Ces investigations techniques seront donc menées durant l’itération précédente : c’est ce qu’on peut appeler la préparation de l’itération. Cependant, cela nécessite d’identifier au préalable quelles sont ces investigations techniques à mener.
3. C’est pourquoi vers la moitié de l’itération précédente, le PO présente à l’équipe quels seront a priori les sujets de l’itération suivante. C’est également l’occasion de faire un point sur le backlog et la roadmap, un moment complémentaire de la Revue de l’itération pour donner une vision globale à l’équipe. Mais surtout, l’équipe connaissant les sujets à venir, peut alors identifier les investigations techniques qui seront nécessaires et qui doivent être menées avant la fin de l’itération.
4. Mais d’où viennent ces sujets qui remplissent le backlog ? Encore en amont, le PO organise des refinements avec l’équipe pour discuter des sujets, mieux les travailler, les formaliser, et les transformer en backlog – notamment en les estimant.

Du point de vue de l’équipe, on peut dérouler ces rituels dans l’ordre chronologique :

1. Le PO demande l’aide de l’équipe lors des refinements pour construire un backlog et l’estimer.
2. A la moitié de l’itération, le PO annonce à l’équipe les sujets qui viendront durant l’itération suivante. L’équipe détermine les investigations techniques nécessaires qui n’auraient pas déjà été identifiées.
3. En parallèle de la fin de l’itération, l’équipe prépare l’itération suivante en menant les investigations techniques identifiées.
4. Lors de la planification d’itération ou Sprint Planning, l’équipe maîtrise suffisamment les sujets pour pouvoir planifier le contenu de l’itération, aussi bien d’un niveau macro (quelles User Stories sont prises) qu’au niveau micro (découpage en tâches techniques).

A noter, plusieurs aller-retours sont possibles entre refinements et investigations techniques lorsque les sujets le nécessitent. C’est un mode de fonctionnement normal, et voulu dans la mesure où on veut réellement rester au niveau du produit lors des refinements : si des investigations techniques sont nécessaires, il vaut mieux couper court au refinement et se revoir une fois qu’elles sont menées.

L’aide à la facilitation

Chaque étape joue donc un rôle différent et complémentaire des autres. La page suivante du document offre un résumé de leurs grandes caractéristiques : quand la réunion a-t-elle lieue, quel est le focus de la réunion, quels en sont les livrables concrets :

Le but est clairement d’aider l’équipe, et en particulier le facilitateur (typiquement le Scrum Master) à cadrer ces réunions en s’assurant que les échanges restent dans le bon état d’esprit et qu’on y construit les bons livrables – en d’autres termes, que la réunion soit constructive !

Faciliter les réunions

Pour aller plus loin dans cette facilitation, chaque étape est détaillée dans une double-page qui lui est consacrée. Sont alors dispensés divers conseils pour aider à cadrer et faciliter la réunion. Il y a par exemple la double-page consacrée au refinement.

La première page indique :

• Le focus de la réunion : pour détecter quand recadrer ou abréger la réunion
• Les livrables concrets de la réunion : pour s’assurer que l’équipe est dans le bon état d’esprit et que la réunion est constructive
• Une description de la réunion : pour rappel, et expliquer aux nouveaux à quoi sert la réunion
• Quels sont les participants de la réunion : pour s’assurer que toutes les personnes pertinentes sont là, mais qu’il n’y a pas de personnes en trop non plus
• Une liste d’outils qui peuvent être utilisés pour faciliter la réunion – eux-mêmes détaillés plus loin dans le document

La seconde page propose :

• Reprise du focus et des livrables concrets de la réunion
• Une liste de problèmes typiques rencontrés dans le cadre de cette réunion, et des conseils pour y remédier : pour pouvoir les détecter et remettre la réunion sur ses rails
• Des conseils à mettre en place pour que la réunion se déroule bien

En tant que facilitateur, j’ouvre mon cahier sur la double-page correspondante à la réunion courante. J’ai sous les yeux toutes les choses que je dois surveiller pour que la réunion se déroule au mieux. C’est également visible aux yeux de tous, qui peuvent participer dans le rôle de facilitation, par exemple en détectant qu’on s’éloigne du focus de la réunion.

Les outils du facilitateur

Les pages suivantes listent les différents outils mentionnés dans les descriptions des réunions. Voici par exemple celles des 3 Amigos et de l’Example Mapping, deux outils qui servent à cadrer les refinements :

Pour chaque outil, la page propose :

• Un descriptif qui explique le principe de l’outil
• Un lien de référence, pour permettre de creuser un peu plus le sujet
• Un dessin ou une photo, permettant d’illustrer la pratique ou de simplement aider à la mémoriser
• Un bloc dispensant des conseils pour réussir la mise en pratique

Là encore, le but est de pouvoir ouvrir mon cahier à la page correspondante pour me permettre d’expliquer le fonctionnement et d’avoir sous les yeux tous les éléments qui m’aideront à s’assurer que la réunion se déroule bien.

Le document à imprimer

Peut-être le plus important : le fameux document que vous pourrez imprimer. C’est réellement dans cette optique que j’ai conçu cet outil de travail, qui désormais m’accompagne et m’aide au quotidien.

Je vous invite donc à le télécharger et à me dire ce que vous en pensez, voire à l’imprimer et l’utiliser !

Facilitation Refinement

Retour d’expérience

Difficultés rencontrées

L’équipe est souvent plus sous pression vers la fin de l’itération que vers le début, conséquence naturelle de l’itération qu’il faut boucler, avec sa Revue d’Itération et sa démo. De fait, l’équipe est généralement plus disponible pour mener les investigations techniques en début d’itération, ce qui ne correspond pas à notre calendrier annonçant les sujets en milieu d’itération.

En pratique, nous essayons de réduire cet effet en sollicitant l’équipe le moins possible en seconde moitié d’itération : nous essayons de ne placer les refinements, lorsqu’ils sont nécessaires, qu’en première moitié d’itération. A l’équipe de s’auto-organiser pour mener les investigations techniques au meilleur moment en parallèle de la fin de l’itération.

Correspondance à notre projet

L’équipe intègre le fait qu’elle doive préparer les itérations suivantes, tout en conservant une certaine flexibilité sur le délai d’ajustement du backlog : on essaie de ne pas préparer plus en avance que l’itération suivante. Cela correspond bien à notre contexte, où les sujets sont connus à l’avance sans pour autant que le backlog ne soit figé.

De plus, notre projet est très technique, et un de nos plus gros problèmes est de réussir à garder nos échanges au niveau du produit. Cette approche nous aide à séparer clairement les différents types de réunion en fonction de leur focus, et pose clairement les limites de quand nous nous écartons du sujet de la réunion.

Ouverture : autres possibilités et comparatif

En guise d’écho à l’avertissement au début de l’article, voici quelques alternatives pour gérer vos préparations d’itérations. Si nous sommes très contents de notre petit framework décrit dans cet article, ce n’est pas une réponse absolue pour tous les projets et toutes les équipes ! Il y a également fort à parier que nous changerons nous-même tôt ou tard de modèle, au fil des évolutions de notre contexte projet, de notre équipe et de notre maturité.

Alternative proche : remplacer les investigations techniques en amont de l’itération par des spikes dans les itérations précédentes

L’idée de base est simple : plutôt que d’alourdir de manière invisible les itérations avec la préparation des itérations suivantes, on matérialise de telles préparations par des spikes qui seront donc intégrées dans le contenu de l’itération.

Bien entendu, cela ne remplace pas complètement le besoin de préparation de l’itération suivante puisqu’utiliser de tels spike n’est pas raisonnable pour des investigations techniques minimales, par exemple de moins d’une heure.

Avantages

On trace clairement le travail d’investigations techniques que mène l’équipe.

Dans l’idée, cela facilitera la construction d’une équipe sereine, qui sera confiante dans ses planifications d’itération.

Inconvénients

Cela peut rallonger d’autant le temps nécessaire en amont de l’itération : une fois un sujet défini et formalisé en refinement, il faut encore identifier les investigations techniques nécessaires, intégrer les spikes correspondantes dans le backlog puis dans les itérations, et faire autant d’aller-retour que nécessaire ; chaque aller-retour pouvant être équivalent à une itération supplémentaire…

Ce premier problème mène à deux risques :

1. Pour que cela fonctionne, l’équipe et notamment le PO doivent être suffisamment organisés pour que ce processus soit mené en amont des itérations. Ils doivent également bien garder note des échanges passés pour rester efficaces au fil des réunions espacées dans le temps.
2. Lorsque le contenu du backlog change, il y a le risque qu’une investigation technique ne soit plus utile ou pertinente. C’est donc du temps perdu, du travail gâché. Plus le délai est grand entre l’investigation technique et le début de l’itération correspondante, plus ce risque est élevé.

Projet cible

Ce mode de fonctionnement nécessite que les sujets soient déjà très bien pris en main par le PO, de sorte que les échanges entre investigations techniques et refinements soient minimaux.

Globalement, cette approche correspondra bien à un backlog qui change peu et dont les contraintes sont très maîtrisées. On pourra donc planifier longtemps en avance les investigations techniques pour démarrer sereinement les itérations.

Cela peut tout de même être une manière intéressante d’avancer avec une équipe disposant d’une faible maturité Agile, en les aidant à se concentrer sur ce qu’ils livrent dans l’itération courante.

Alternative radicale : réduire au maximum la préparation en amont de l’itération

Si on revient à l’essence des choses… Quel est le strict minimum requis pour pouvoir « faire entrer » un sujet dans l’itération ?

1. On doit être capable de prioriser le sujet
2. Le sujet doit être suffisamment petit

Bien entendu, l’équipe devra creuser les sujets avant de pouvoir commencer à coder. Bien entendu, elle devra s’assurer d’avoir bien compris les besoins métier. Bien entendu, elle devra s’orienter vers une solution technique pérenne… Mais l’idée est de répondre à toutes ces questions pendant l’itération !

Fondamentalement, cette approche correspond à l’essence de Scrum telle qu’on peut la lire dans le Scrum Guide, puisque :

• Des feedbacks et ajustement de roadmap et de backlog peuvent intervenir jusqu’au dernier moment de l’itération, notamment pendant la revue d’itération (Sprint Review) où toute l’équipe ainsi que les parties prenantes échangent justement de ces questions
• En Rétrospective, même si ce n’est pas le sujet principal, on peut imaginer que l’introspection de l’équipe sur l’itération passée mène à prioriser différemment certains sujets
• Enfin, c’est seulement au moment de la planification d’itération (Sprint Planning) que tombent définitivement les sujets de l’itération

Avantages

C’est le plus Lean ! Si les sujets changent au dernier moment, il n’y a quasiment pas de travail perdu, de déchet, puisque l’équipe n’a passé qu’un temps minimal à préparer les sujets qu’on écarte.

Il en résulte une plus grande réactivité de l’équipe. Dès qu’un sujet important fait surface, il peut être pris par l’équipe, quasiment sans délai, lors de l’itération suivante. Même si le sujet arrive très tardivement avant le démarrage de l’itération.

La vélocité de l’équipe sera, paradoxalement, la plus fidèle possible, dans la mesure où elle inclura également toutes les tâches annexes de préparation des sujets. La vélocité de l’équipe prendra ces sujets en compte, plutôt que de la mettre de côté ce qui peut biaiser cette mesure, par exemple avec des sujets qui seraient petits à implanter mais qui nécessiteraient beaucoup de discussions préalables pour décider de la bonne manière de faire.

Inconvénients

Quasi-nécessité d’avoir la main sur un client, pour pouvoir creuser les sujets en dehors de réunions fixées à l’avance. Ce qui, en soit, est reconnu comme un énorme atout pour mettre en place Scrum ou n’importe quelle méthode Agile. Si à l’inverse il est long ou difficile d’obtenir un feedback client, alors l’approche risque de mettre à mal les itérations… Et il y a fort à parier qu’au fil des itérations et des Rétrospectives l’équipe va définir la nécessité d’un Definition of Ready et mécaniquement s’éloigner de cette méthode de planification.

Finalement, ce mode de fonctionnement implique une forte maturité Agile de l’équipe, et dans une certaine mesure de l’organisation et de ses clients.

Projet cible

Si la balance penche vers Kanban plutôt que Scrum, si vous ne retirez pas un intérêt fort des planifications à moyen et long terme… Si vous changez souvent le contenu de l’itération au dernier moment ! Enfin et surtout, si vous êtes plutôt dans un environnement type start-up où la réactivité est essentielle !

Questions fréquemment posées :