Sprint dans le développement mobile : essence, durée et planification

Qu'est-ce qu'un sprint en développement ?

Sprint est une timebox de durée fixe à l'issue de laquelle l'équipe livre un incrément du produit prêt à l'emploi. Le concept de sprint est le fondement de Scrum, mais il est également utilisé dans d'autres frameworks Agile. Dans le développement mobile, un incrément est un build de l'application qui peut être installé sur un appareil, testé et présenté aux parties prenantes. Un sprint ne peut pas être prolongé — si les tâches ne sont pas terminées, elles sont déplacées vers le sprint suivant.

La caractéristique clé d'un sprint est la durée fixe. L'équipe ne modifie pas l'objectif du sprint après approbation. Cela offre de la prévisibilité : les parties prenantes savent quand elles recevront le résultat. Au sein du sprint, l'équipe décide comment répartir le travail. Le Scrum Master protège l'équipe des interférences externes — aucune nouvelle tâche n'est ajoutée au sprint en cours. Selon le Scrum Guide 2025, c'est la seule façon de maintenir un rythme de développement durable.

Un sprint se compose de quatre événements obligatoires : Sprint Planning, Daily Scrum (synchronisation quotidienne), Sprint Review (démonstration du résultat), Sprint Retrospective (analyse du processus). Entre eux se trouve le travail principal : implémentation des tâches, tests, code review. Durée de chaque événement est directement proportionnelle à la longueur du sprint : pour un sprint de 2 semaines, le Planning dure 4 heures, le Review 2 heures, la Retro 1,5 heure, le Daily 15 minutes. Au total, les rituels prennent environ 8 heures par sprint — 10 % du temps de travail de l'équipe.

Rituels Scrum du sprint

Rituels Scrum (cérémonies/événements) sont des réunions d'équipe structurées au sein du sprint. Sprint Planning au début, Daily Scrum chaque jour, Sprint Review et Retrospective à la fin. Tous les événements ont une timebox. Le Scrum Master assure le respect de la timebox et de la concentration. Toute l'équipe Scrum participe à chaque rituel : Product Owner, Scrum Master, développeurs. L'exception est le Daily Scrum (seuls les développeurs participent, PO et SM sont facultatifs).

Le lien des rituels avec les étapes du sprint : le Planning donne la direction (quoi et comment nous faisons), le Daily synchronise (qui fait quoi, quels bloqueurs), le Review montre le résultat (ce qui a été fait, ce qui ne l'a pas été), la Retrospective améliore le processus (comment rendre le prochain sprint meilleur). Sauter la rétrospective est l'erreur la plus courante des équipes : lorsque les délais sont serrés, c'est la Retro qui est sacrifiée en premier. Cela conduit à une stagnation des processus et à la répétition des mêmes erreurs. La recherche de Scrum.org (2025) montre que les équipes qui font une Retro toutes les 2 semaines améliorent leur vélocité 35 % plus rapidement.

Sprint Planning : planification de l'itération

Sprint Planning est une réunion d'équipe au début du sprint où il est déterminé ce qui sera fait et comment. Le Product Owner présente les tâches prioritaires du Product Backlog. L'équipe estime la capacité (temps disponible en tenant compte des vacances, réunions, dette technique) et sélectionne les tâches qu'elle peut accomplir pendant le sprint. Le résultat du Planning est le Sprint Goal (objectif du sprint) et le Sprint Backlog (liste des tâches). Le Sprint Goal est formulé comme une phrase courte : « Implémenter l'écran de commande et l'intégration de paiement via SBP. »

Vélocité est la vitesse de l'équipe mesurée en story points par sprint. Moyenne des 3 à 5 derniers sprints. Selon Scrum.org (2025), une équipe de 5 développeurs mobiles (3 Android + 2 iOS) a une vélocité de 25 à 40 SP par sprint de 2 semaines. Le Planning utilise la vélocité comme limite supérieure — ils prennent 10 à 15 % de moins pour tenir compte des tâches imprévues (code review, incidents, aide aux autres équipes). Capacité vs Vélocité : la capacité est les « heures-personnes », la vélocité est les « story points ». La capacité tient compte des vacances, des arrêts maladie, des réunions. Le taux de perte typique est de 25 à 30 % du temps de travail consacré à des activités non liées au code.

Le Planning est divisé en deux parties : « quoi » (PO décrit les tâches, l'équipe clarifie) — 2 heures, et « comment » (l'équipe décompose et estime) — 2 heures. Pour les projets mobiles, dans le « comment », on discute : compatibilité avec les versions Android/iOS, nécessité des feature flags, impact sur la taille de l'APK/IPA, nouvelles autorisations. Technique du Planning Poker est utilisée pour l'estimation : chaque développeur donne son estimation en story points (1, 2, 3, 5, 8, 13). Un écart de plus de 2 unités déclenche une discussion des raisons. Cela révèle les risques cachés à l'étape de planification, pas au milieu du sprint.

Exécution du sprint : Daily Standup et suivi

Daily Scrum (Standup) est une réunion quotidienne de 15 minutes pour la synchronisation de l'équipe. Chaque participant répond à trois questions : « Qu'est-ce qui a été fait hier ? », « Que prévois-je de faire aujourd'hui ? », « Quels bloqueurs ai-je ? » Le Daily n'est pas un rapport d'avancement pour le manager, mais un outil d'auto-organisation de l'équipe. Si lors du Daily il s'avère que deux développeurs travaillent sur la même tâche — c'est un signal de réorganisation. Important : le Daily ne résout pas les problèmes mais les identifie — une réunion séparée est convoquée après le Daily pour les résoudre.

Scrum Board (tableau du sprint) est une visualisation du Sprint Backlog. Colonnes : To Do / In Progress / In Review / Done. Chaque tâche se déplace sur le tableau. Le Burndown Chart est un graphique du travail restant par jour du sprint. Le burndown idéal est une ligne droite du SP total à 0. Le burndown réel est un graphique en escalier reflétant la fermeture des tâches. Un burndown descendant (en dessous de la ligne idéale) signifie que nous sommes en retard. Signal de problème : si moins de 30 % des tâches sont terminées à la mi-sprint — un ajustement est nécessaire. Les risques peuvent ne pas avoir été pris en compte ou les tâches ont été surestimées.

Pour le développement mobile, le suivi du sprint est affecté par des facteurs spécifiques : temps de build (la compilation d'un projet Android dans le CI peut prendre 30 minutes ou plus), attente de la modération de l'App Store / Google Play (si un build doit être publié aux testeurs via TestFlight), compatibilité avec différents appareils (tester sur 10+ modèles prend du temps). Conseil : réservez 1 jour de marge à la fin du sprint pour les tests finaux et l'assemblage du build de release. Cela réduit le risque de sprint incomplet de 40 % selon Mind the Product (2025).

Sprint Review et Retrospective

Sprint Review est une démonstration de l'incrément aux parties prenantes. L'équipe montre un build fonctionnel de l'application, pas des diapositives. La durée est de 2 heures pour un sprint de 2 semaines. Le Product Owner vérifie la conformité aux Acceptance Criteria. Les parties prenantes fournissent des retours qui peuvent affecter le Product Backlog. Le Review n'est pas un rapport mais un dialogue : les parties prenantes peuvent poser des questions et suggérer des changements. Règle clé : le Sprint Review porte sur le produit, pas sur le processus. Montrez ce qui a été accompli, pas comment cela a été fait.

Sprint Retrospective est une réunion interne de l'équipe pour analyser le sprint passé. Format : Start Doing (quoi commencer à faire), Stop Doing (quoi arrêter de faire), Continue Doing (quoi continuer à faire). La durée est de 1,5 heure pour un sprint de 2 semaines. La Retrospective est un espace sûr pour discuter des problèmes. Règle : dans la Retro, les détails techniques ne sont pas discutés (il y a des réunions techniques pour cela). Seulement le processus, la communication, les outils, la culture. Le Scrum Master facilite la réunion et s'assure que chaque participant s'exprime.

Le résultat de la Retrospective est de 1 à 3 améliorations pour le prochain sprint. Si l'équipe a identifié le problème « La code review prend trop de temps » — action item : « Fixer un SLA pour la review — 4 heures. Si la review n'est pas faite à temps — le développeur rappelle dans Slack. » Action Items doivent être spécifiques, mesurables et attribués à une personne spécifique. Selon Atlassian (2025), les équipes qui exécutent leurs action items de Retro améliorent leur vélocité de 15 à 25 % en 3 à 4 sprints. Celles qui ne le font pas stagnent.

Comment choisir la durée du sprint

2 semaines est la norme pour le développement mobile. L'équilibre optimal entre prévisibilité et flexibilité. Assez de temps pour : planifier, implémenter 3 à 5 fonctionnalités moyennes, tester, montrer les résultats. 1 semaine est pour les équipes ayant une maturité de processus élevée et un CI/CD. Nécessite des décisions rapides, un minimum de bureaucratie. Convient aux startups en phase précoce qui ont besoin d'expérimenter rapidement. Inconvénient : surcharge élevée des rituels (Planning + Review + Retro chaque semaine = 7,5 heures).

3 à 4 semaines sont pour les projets complexes impliquant une intégration matérielle (wearables, IoT, appareils BLE), une modération longue des stores ou des migrations importantes (par exemple, transition de RxJava vers Coroutines). Les sprints longs offrent plus de temps pour les tests mais augmentent le risque de l'« effet cascade » — l'équipe perd la flexibilité Agile. Recommandation du Scrum Guide : ne pas dépasser 1 mois. Si le sprint est plus long, il y aura trop de contexte lors du Review et les parties prenantes ne pourront pas fournir des retours de qualité.

Problèmes typiques des sprints

Problème 1 : Scope Creep. Au milieu d'un sprint, le Product Owner ajoute une nouvelle tâche « urgente et importante ». L'équipe accepte — et le sprint échoue. Solution : le Sprint Goal est un contrat. Tout changement nécessite une révision du Sprint Goal, ce qui n'est possible qu'en cas d'urgence. La nouvelle tâche va dans le Product Backlog et dans le prochain sprint. Si la tâche est vraiment critique — l'ancien Sprint Goal est annulé, le sprint est replanifié, mais c'est une exception, pas une pratique. Une fréquence de scope creep supérieure à une fois tous les 3 sprints est le signe d'un Product Owner faible.

Problème 2 : Tâches incomplètes. À la fin du sprint, 50 % des tâches sont In Progress, 20 % In Review, seulement 30 % Done. Raisons : capacité surestimée, complexité sous-estimée, bugs non planifiés. Solution : analysez la raison lors de la Retro. Si vous ne parvenez pas systématiquement à suivre — n'augmentez pas le nombre de tâches dans le Planning, diminuez-les. Les équipes qui prennent 20 % moins de tâches montrent un taux d'achèvement plus élevé (80 %+ contre 50-60 %). Liste de vérification pour le Planning : pour chaque tâche, vérifier les Acceptance Criteria, la Definition of Ready et la dépendance avec d'autres tâches.

Problème 3 : Retro formelle. L'équipe fait une Retro pour la forme — 15 minutes, phrases génériques, pas d'action items. Solution : changez le format de chaque Retro. Méthodes : Sailboat (ce qui ralentit, ce qui accélère), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Attribuez des action items avec des délais et des responsables. Au début de la Retro suivante, vérifiez l'accomplissement des action items précédents. Selon Atlassian (2025), les équipes qui utilisent différents formats de Retro génèrent 50 % plus d'informations utiles.