Tout ce que vous devez savoir sur les Sprints Agiles !

Les méthodes Agiles dans le développement de produits sont maintenant incontournables. L’approche la plus répandue, Scrum, s’oriente vers la collaboration d’équipe et offre un cadre de travail qui permet d’agir à la fois de façon itérative et incrémentale pour être en perpétuelle amélioration.

Scrum décrit un système de rôles, de rituels, d'artefacts et de règles qui fonctionnent ensemble pour aider les équipes à organiser et à gérer leur travail. Une des premières notions à mettre en place dans le cadre du framework Scrum est le Sprint. Et si vous vous interrogez sur la valeur d’un Sprint, cet article est fait pour vous !

Qu’est-ce qu’un Sprint?

Dans une équipe Scrum, on crée des produits complexes en les décomposant par itérations courtes, afin de construire le produit pas à pas, en conservant de la souplesse au fil du temps. Ces itérations sont des Sprints.

Waterfall vs Agilité

Un Sprint est réalisé sur une courte période limitée dans le temps pendant laquelle une équipe Scrum travaille à la réalisation des différentes User Stories engagées dans le Sprint Backlog.

Les Sprints ( avec les cérémonies) rythment la vie de l’équipe et du produit. Ils permettent plus de flexibilité et d’adaptation (plus facile et moins coûteuse) au changement.

📚 Lire notre article sur la bonne rédaction des User Stories.

En effet, le sprint traduit une des 4 valeurs du Manifeste Agile :

• Les individus et les interactions plutôt que les outils et les processus
• La qualité fonctionnelle plutôt que la réalisation de documentations techniques (il ne s’agit pas d’oublier la documentation, mais de la produire au fil de l’eau, lorsqu’elle est réellement nécessaire au développement)
• La collaboration avec le client plutôt que les négociations contractuelles
• La flexibilité permettant de réagir facilement à l’évolution de la demande plutôt que le suivi d’un plan défini en amont

Le terme “Sprint” n’est d’ailleurs pas choisi au hasard, ce mot est bien tiré du sport où un coureur tente d’atteindre un objectif de performance sur une durée courte.

Cela permet d’insister : un sprint, c’est avancer en équipe selon le(s) objectif(s) définis en se focalisant à atteindre ces objectifs.

Pour aller plus loin sur les prémices des Sprints, l’idée a été inspirée de l’étude “The New New Product Development Game” (1986) qui expérimentait de nouvelles méthodes de gestion de projet basées sur les concepts d’itération :

“as in rugby, the ball gets passed within the team as it moves as a unit up the field.”

“a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements”

Source:

Chronologie d’un Sprint

Déroulement d’un sprint: cérémonies & artefacts - Source : Hubvisory

Le top départ d’un Sprint, c’est le Sprint Planning.

Lors de cette cérémonie, l’équipe se réunit pour décider ensemble du contenu des développements du sprint à venir : quelles features et User Stories du Product Backlog sont embarquées dans le Sprint Backlog ? la liste des User Stories que l’on souhaite réaliser durant le Sprint à venir ?

On définit également un ou des objectifs de Sprint, cohérents avec la vision produit. A la sortie de cette cérémonie, l’ensemble de l’équipe est au clair sur les réalisations attendues pour les X prochains jours.

📚 Lire notre article sur le Sprint Planning

Durant le Sprint, l’équipe se rencontre tous les jours lors du Daily meeting pour partager l’avancée de la réalisation des différentes User Stories et informer les membres de l’équipe d’éventuels points bloquants ou problèmes pouvant freiner la course.

L’équipe se rencontre également à l’occasion d’autres rituels : de préparation des sprints suivants avec la réunion d’affinage, ou le poker planning, de validation des User stories, tests techniques, fonctionnels …

📚 Lire notre article sur le Daily Meeting.

La fin d’un Sprint est marquée par la Revue de Sprint ou Sprint Review. Lors de cette cérémonie, une démonstration des fonctionnalités développées est faite à toutes les parties prenantes du produit (clients / responsables hiérarchiques / facilitateurs techniques ou opérationnels…) en présence de l’équipe Scrum. Une autre cérémonie ponctue le sprint: la rétrospective. Elle permet aux membres d’une équipe d’échanger sur le vécu du sprint afin de pouvoir s’améliorer sur les suivants.

A noter que la fin d’un Sprint peut être marquée ou non par la mise en production des fonctionnalités développées. Cela dépend du produit !

📚 Lire notre article sur la rétrospective de sprint.

Chaque Sprint apporte sa pierre à l’édifice pour réaliser la vision produit. L’incrément produit, qui est le résultat concaténé du Sprint et de tous les Sprints précédents, représente la concrétisation de cette vision.

Les objectifs de Sprint

Un “Sprint Goal” est un objectif fixé pour le Sprint qui peut être atteint grâce à la réalisation du Sprint Backlog (liste de User Stories priorisées). Les objectifs de Sprint sont le résultat d'une réflexion collective du Product Owner et de l'équipe de développement.

Ces objectifs doivent être spécifiques et mesurables. Alors que le travail sélectionné pour le Sprint Backlog représente une prévision, l'équipe de développement s'engage à atteindre l'objectif de Sprint (ou Sprint Goal).

Quelques exemple d’objectifs :

• Préparer la fonctionnalité X (l'objectif de Sprint fournit une fonctionnalité)
• Vérifier si l'architecture permet les performances souhaitées (ici, l'objectif de Sprint traite un risque)
• Tester si les utilisateurs sont prêts à s'inscrire avant d'utiliser les fonctionnalités du produit (ici, l'objectif de Sprint teste une hypothèse)

Les intérêts du Sprint Goal sont nombreux :

• donner un focus pour l’équipe (notamment au cours du Daily)
• simplifier le suivi pour les takeholders
• fixer une priorité vers laquelle se concentrer si le Sprint est en péril...

Combien de temps doit durer un Sprint?

La durée d’un Sprint en théorie

En théorie, un Sprint dure entre 1 et 4 semaines. Il doit être suffisamment long pour réaliser plusieurs User Stories mais suffisamment court pour pouvoir intégrer régulièrement les feedbacks ou ajustements des utilisateurs.

En général, les équipes Scrum fonctionnent sur des Sprints de 2 semaines mais il s’agit de voir ce qui fonctionne le mieux pour votre équipe et pour votre produit.

En effet, chaque équipe est constituée différemment pour répondre à ses propres contraintes (technologie, complexité de l’environnement …). Chaque durée présente des avantages et des inconvénients. A vous donc d’identifier ce qui vous convient le mieux.

Deux règles, néanmoins, concernant la durée des Sprints :

• La durée d’un Sprint ne peut être changée après le démarrage de ce dernier. La fin d’un Sprint n’est pas une deadline mais l’occasion de faire un bilan, de prendre du recul sur ce qui a été réalisé ou non, de récolter des feedbacks et d’identifier des axes d’amélioration.
• Tous les Sprints doivent être de la même durée. Cela permet de donner un rythme régulier, notamment pour les revues avec les équipes métier ou pour construire une vélocité fiable qui permettra de bien planifier les futurs Sprints.*

*Bien sûr, lorsque vous démarrez une équipe Scrum, un temps d'adaptation peut être nécessaire pour trouver la meilleure durée de Sprint.

Nos retours d’expérience

Chez Hubvisory, nous sommes 50 Product Managers et Coachs, experts de l’agilité alors des Sprints, on en a vu beaucoup.

Voici quelques pros & cons qu’on a identifié lorsque l’on sort des deux semaines traditionnelles :

Sprint d’une semaine :

• Pros :
• Dynamique, les Sprints d’une semaine permettent de créer de la valeur très rapidement
• Les rétrospectives de Sprint toutes les semaines permettent de rebondir sur des sujets “frais” et d’aborder tous les sujets
• Cette courte durée permet de pivoter beaucoup plus rapidement, elle offre encore plus de flexibilité
• Cons :
• Le Sprint peut paraître plus “lourd” car les cérémonies sont plus récurrentes, si certaines peuvent être plus raccourcies (rétro, grooming …), c’est difficilement possible pour d’autres (les revues de Sprint notamment)
• Autre aspect à considérer d’un point de vue Product Manager : ce format de Sprint court peut apporter plus de pression pour avoir des User Stories prêtes, des conceptions prêtes. Le travail en amont qui est très important doit être réalisé plus rapidement
• Enfin, cela demande une bonne gestion de l’équipe de développement pour savoir alterner entre les plages de dev, les reviews, et les cérémonies.

Sprint de 3 semaines et plus :

• Pros:
• Cela donne le temps de développer de belles fonctionnalités de bout en bout, ce qui est apprécié auprès des métiers/stakeholders
• Ces Sprints, plus longs, évitent une surcharge des cérémonies, offrent une meilleure gestion des devs et moins de stress
• En tant que Product Owner, vous bénéficiez de plus de temps pour identifier et préparer les nouveaux sujets (organiser des ateliers utilisateurs, créer et affiner les User Stories, gérer les allers-retours avec l'UX Designer et les métiers)
• Sur trois semaines, la vélocité est également plus facile à lisser
• Cons :
• L’inconvénient principal évoqué par nos Hubvisors est que les cérémonies sont plus lourdes (en contenu ainsi qu’en durée) notamment le Sprint Planning et la Revue de Sprint.
• Un plus gros travail de préparation est nécessaire pour alimenter le backlog (puisqu’un plus grand nombre de User Stories est nécessaire).

Une équipe nouvellement Scrum peut avoir besoin de plusieurs Sprints avant de trouver son rythme idéal. C’est bien là une des valeurs de l’Agilité : le test and learn (qui s’applique aussi bien pour le produit que pour l’équipe elle-même).

En conclusion : itérez !

Le Sprint est une notion fondamentale de la méthode Scrum et rythme la vie d’une équipe produit. Cet article vous a présenté ses théories et nos retours d’expérience mais chaque équipe est différente, alors … itérez !