Scrum : Comment réussir son premier sprint ?

ça y est, vous vous êtes appropriés le guide Scrum avec votre équipe, vous savez ce qu'est un sprint en Scrum, et vous êtes fin prêts à démarrer vos premières itérations agiles. 

Je vous explique dans cet article comment mettre toutes les chances de votre côté et réussir votre premier sprint.

10 astuces pour bien gérer son premier sprint

Le premier sprint sur un projet Scrum est le sprint 1, pas le sprint zéro. Bien que celui-ci soit utile dans certains cas, il n'existe pas officiellement dans le guide Scrum.

Pour autant, ce premier sprint est d'une importance capitale, et risque de façonner la réussite ou l'échec de votre projet.

Ces 10 conseils vont vous permettre de mieux appréhender ce premier sprint et d'en tirer la quintessence.

1 ) Présenter le projet et le product backlog avant le premier sprint

Si l'équipe Scrum est prête à démarrer le premier sprint, c'est qu'il existe un produit à développer. Et qui dit produit dit objectif de produit et product backlog.

• Objectif de produit (Product goal).
  Il s'agit de l'objectif à long terme à atteindre via ce projet. Il décrit un état futur du produit.
  
• Backlog de produit (Product backlog).
  Il contient des éléments ordonnés et priorisés, qui devront être développés par l'équipe afin d'atteindre l'objectif de produit.
  

Prenez quelques heures avant le démarrage officiel du premier sprint afin de présenter le projet à l'équipe. L'équipe doit avoir une vision claire de l'objectif de produit et de ce qu'on souhaite accomplir.

Présentez également le product backlog dans son état actuel, contenant les premiers éléments priorisés.

Pas besoin de détailler ces éléments, cela se fera un peu plus tard. l'idée ici est que l'équipe se fasse une première idée du projet et comprenne ce sur quoi elle va travailler ces prochains mois.

2 ) Le premier sprint n'est pas un sprint de cadrage

Soyons clairs, le premier sprint n'est PAS un sprint de cadrage, ni un sprint 0.

L'utiliser comme une phase de cadrage déguisée comme on peut le faire dans les méthodologies de gestion de projet traditionnelles, ça ne marche pas. En tout cas, ce n'est pas du Scrum, et ce n'est certainement pas de l'agilité.

L'incrément du premier sprint (son résultat) doit apporter de la valeur business immédiate au client et aux utilisateurs finaux. Il ne s'agit pas d'un sprint "technique" permettant de poser l'architecture de base, car dans ce cas vous n'avez rien à montrer au client.

L'infrastructure technique émerge au fur et à mesure des sprints et des besoins, elle n'est pas posée à l'avance. Sinon vous revenez à la phase de cadrage que l'on souhaite éviter.

3 ) Il n'est pas différent des autres sprints

 Le premier sprint est un sprint comme les autres. Il n'a rien d'extraordinaire, il n'a rien qui le démarque des autres, sauf qu'il est le premier.

Il est donc organisé de la même manière :

• Sprint planning.
  A lieu au démarrage du sprint, et permet de choisir l'objectif de sprint et de sélectionner le travail à réaliser et le plan d'action pour atteindre l'objectif.
  
• Daily Scrum.
  Réunion quotidienne de 15 minutes, pendant laquelle l'équipe réfléchit à la meilleure manière d'atteindre l'objectif de sprint.
  
• Sprint review.
  Réunion organisée en fin de sprint avec les parties prenantes afin de présenter le travail réalisé durant le sprint et fini à 100% selon la définition de fini. C'est l'occasion de recueillir du feedback et d'échanger sur la manière de faire évoluer le produit.
  
• Sprint rétrospective.
  Clôture le sprint, et permet de l'analyser afin de faire ressortir des axes d'amélioration pour améliorer l'efficacité de l'équipe et pour améliorer le produit.
  

4 ) Choisir une durée de sprint adéquat

Un sprint peut durer de 1 à 4 semaines, 4 étant le maximum autorisé par le guide Scrum. 

Des sprints d'une semaine sont souvent jugés trop courts par l'équipe de développement et trop contraignant par les parties prenantes.

Au contraire, des sprints d'un mois sont souvent jugés trop longs. Ils ne permettent pas suffisamment d'échanges et de feedback pour améliorer le produit.

Le bon compromis est donc d'avoir des sprints de deux semaines, qui offrent la place nécessaire pour l'adaptation et l'amélioration continue du produit et de l'équipe.

Attention cependant. Une fois la durée d'un sprint choisie, vous ne pourrez plus revenir dessus. Tous vos sprints devront avoir cette durée sur ce projet.

Tant que vous y êtes, je vous recommande également de choisir avec l'équipe le jour idéal pour démarrer de nouveaux sprints. Personnellement je préfère le Mercredi, mais c'est à vous de voir. Je vous explique comment choisir le bon jour pour commencer vos sprints dans cet article.

5 ) Penser MVP pour organiser le sprint

Si vous pensez livrer le produit fonctionnalité par fonctionnalité, revoyez votre copie.

Si votre client vous demande comme produit un véhicule à 4 roues à l'arrivée, vous n'allez pas lui livrer un volant au sprint 1, des roues au sprint 2 et ainsi de suite.

L'incrément d'un sprint doit être utilisable et apporter de la valeur immédiatement.

La bonne manière de faire est de penser MVP : Minimum Viable Product, ou Produit Minimum Viable.

Voyez ce premier sprint comme un voyage pour découvrir vi l'empirisme comment apporter de la valeur rapidement à votre client en faisant le produit le moins compliqué possible, et avec le moins de fonctionnalités possible.

Prenons un exemple.

Exemple concret

Imaginons que votre client veuille avoir à l'arrivée un site de e-commerce, véritable marketplace à la Amazon ou Cdiscount.

Le boulot est énorme pour y arriver.

Mais alors, quel pourrait être le MVP ? Qu'est-ce qu'on pourrait dès le sprint 1 qui apporterait de la valeur business ?

Quelque chose de tout simple. Par exemple une simple page web permettant de commander un produit. Lorsqu'on clique sur le bouton, il n'y a pas de renvoi vers Paypal, pas d'automatisation, rien. Si ce n'est que les coordonnées du client sont inscrites dans un fichier.

L'équipe commerciale peut dès à présent commencer à vendre ce produit sans attendre via cette page, quitte à traiter à la main la commande.

L'automatisation viendra dans un second temps et fera sûrement l'objet d'un futur objectif de sprint.

6 ) Émettre des hypothèses lors du sprint planning

Lors du premier sprint, vous n'avez qu'une connaissance sommaire du produit et des souhaits des utilisateurs finaux. Le product owner, en qualité de représentant des parties prenantes, peut aider l'équipe, mais lui-même ne dispose que d'une vision tronquée.

Par rapport à l'objectif de produit, l'équipe Scrum est donc forcée d'émettre sur ce qui peut apporter le plus de valeur le plus rapidement et qui est réalisable sur ce premier sprint.

Elle fixe alors un objectif de sprint, puis commence à déplacer des éléments du product backlog vers le sprint backlog pour passer en développement.

Elle peut également décider d'ajouter de nouveaux éléments au sprint backlog ou au product backlog, en fonction de ce qu'elle juge nécessaire pour atteindre l'objectif.

Ces hypothèses seront confirmées ou infirmées via le feedback des utilisateurs. C'est le principe même de l'empirisme.

Ce que vous avez livré à la fin du premier sprint ne convient pas ? Top ! Vous savez un peu mieux ce qu'attendent les utilisateurs finaux du produit, et vous pouvez vous adapter sans attendre.

7 ) Techniques d'estimation sans historique de vélocité

Comment peut-on estimer le nombre d'éléments à intégrer au sprint backlog si on ne connaît pas la vélocité de l'équipe ?

La vélocité de l'équipe, c'est le nombre de points d'efforts que l'équipe est en mesure de réaliser durant un sprint. Je vous explique ce concept plus en détails et comment le calculer dans cet article.

En effet, pour estimer le nombre de fonctionnalités à développer dans un sprint, on regarde souvent ce qui s'est passé sur les sprints précédents. Mais dans notre cas on n'a pas d'historique, vu que c'est le premier sprint. Alors comment faire ?

C'est à l'équipe de développement de le sentir. La décision finale lui revient. Ce sprint servira d'étalon pour les suivants.

Dans tous les cas, la date de fin du sprint est connue à l'avance et ne peut pas être décalée.

• Et si l'équipe a fini le travail avant la fin du sprint ?
  Si l'objectif de sprint est atteint avant la fin, l'équipe Scrum peut voir pour intégrer d'autres tâches et s'avancer, notamment sur des tâches techniques ou des axes d'amélioration qu'elle aurait dores et déjà identifié.
  
• Et si il reste des éléments dans le sprint backlog alors que le sprint est terminé ?
  Le travail fini à 100% est présenté aux parties prenantes lors de la sprint review. Le reste à faire est réinjecté dans le product backlog pour nouvelle estimation et nouvelle priorisation.
  

8 ) Faire évoluer le sprint backlog en cours de route

Le backlog de sprint est quelque chose d'émergent et d'évolutif : il n'est pas figé, contrairement à l'objectif de sprint.

L'équipe Scrum doit donc faire vivre ce sprint backlog durant tout le sprint, et y ajouter tout élément qu'elle juge nécessaire afin d'atteindre l'objectif de sprint qui a été défini.

Quand on y réfléchit, c'est totalement normal. Il y a toujours un gap entre ce qu'on pense devoir faire et ce qu'il faut réellement faire.

L'équipe apprend au fur et à mesure du sprint, et tire des leçons de cet apprentissage. Le plan est adapté en cours de route.

C'est une belle preuve d'empirisme. 😉

9 ) Ne pas attendre la sprint review pour obtenir du feedback

A chaque fois qu'un élément du sprint backlog est réalisé et 100% terminé, cela crée un nouvel incrément. 

Ces incréments s'additionnent tout au long du sprint jusqu'à former ce qu'on appelle l'incrément du sprint.

Il est tentant d'attendre la sprint review afin de présenter l'intégralité du travail accompli lors du sprint et d'obtenir du feedback. C'est une fausse bonne idée.

Dès qu'un travail est terminé à 100%, livrez-le sans attendre aux utilisateurs, pour avoir un premier feedback immédiat. Cela pourrait vous permettre dores et déjà d'améliorer cet incrément avant la sprint review.

C'est une des manières de maximiser la valeur délivrée à chaque sprint.

10 ) Choisir un axe d'amélioration en rétrospective

ça  y est, vous êtes arrivé à la fin de votre premier sprint. Félicitations !

il est maintenant temps de faire le bilan et d'analyser ce qui s'est passé en détail. Discutez-en en équipe, et identifiez ensemble au minimum 1 axe d'amélioration sur lequel travailler lors du prochain sprint.

L'amélioration continue est au cœur de Scrum, c'est pourquoi j'insiste sur le fait de traiter au moins 1 axe d'amélioration par sprint.

Vous avez sûrement appris beaucoup de choses lors de ce premier sprint sur le produit à développer, le contexte dans lequel il évolue, sur la manière de travailler ensemble. Et même si tout a bien fonctionné, il y a sûrement quelque chose à faire pour que ça fonctionne encore mieux.

Si vous rencontrez des difficultés à identifier un axe d'amélioration, discutez-en avec le Scrum Master, qui pourra vous aiguiller.

Quoi faire à la fin du premier sprint ?

Le premier sprint n'est pas différent des autres, il commence et se termine de la même manière. Vous devez donc organiser deux cérémonies : la sprint review et la rétrospective.

1. La sprint review.
   Vous présenterez le travail accompli durant le sprint et 100% terminé (qu'on nomme incrément de sprint) aux parties prenantes du projet. Ne voyez pas ça que comme une démo, mais plutôt comme un atelier de travail.
   
   Vous récolterez du feedback précieux lors de ce premier échange, qui vous permettra de réagencer le product backlog et les objectifs des prochains sprints.
   
2. La rétrospective.
   Dernière cérémonie qui clôture le sprint, la rétrospective sert à faire le bilan du sprint écoulé. L'objectif de l'équipe est d'identifier des axes d'amélioration et pour le produit, et pour l'organisation de l'équipe.
   
   Je vous conseille d'identifier à la fois ce qui s'est bien passé (et peut être renforcé), et à la fois les difficultés rencontrées (et peut être amélioré).
   

Faut-il faire un sprint zéro avant le premier sprint ?

Certaines équipes Scrum organise ce qu'elles appellent un sprint zéro avant le premier sprint. Il s'agit d'un sprint de cadrage, permettant à l'équipe de découvrir comment travailler ensemble, et d'appréhender le projet.

Cette notion de sprint zéro n'est pas officielle, bien qu'elle puisse être utile dans certains cas. D'ailleurs, je me pose la question de savoir si ce sprint zéro est vraiment agile et utile dans cet article. N'hésitez pas à le consulter.

Personnellement, je n'aime pas ce sprint zéro, qui rappelle trop une phase de cadrage. Je préfère que l'équipe prenne quelques jours pour s'organiser d'elle-même, de manière plus informelle.