Grooming des tâches dans le développement mobile : définition, objectifs et processus

Qu’est-ce que le grooming de tâches ?

Backlog Grooming (affinage) est le processus de préparation des éléments du Product Backlog pour les sprints à venir. C’est une réunion où le Product Owner et l’équipe de développement passent en revue les tâches : clarifient les exigences, ajoutent des Acceptance Criteria, estiment la complexité, identifient les dépendances et les risques. Il n’y a pas d’événement obligatoire appelé « grooming » dans le Scrum Guide — c’est une pratique supplémentaire que les équipes Scrum adoptent pour réduire l’incertitude lors du Sprint Planning. La fréquence recommandée est d’une fois par sprint, d’une durée maximale de 60 minutes.

Le terme « grooming » reflète l’essence : l’équipe « peigne » le backlog, supprime les tâches obsolètes, clarifie les ambiguës et divise celles qui sont trop grandes. Dans le développement mobile, le grooming est particulièrement important en raison des spécificités de la plateforme : une tâche Android peut différer en complexité de sa version iOS, et il faut tenir compte de targetSdk, compileSdk et de la compatibilité avec les niveaux d’API. Sans grooming, le Sprint Planning devient chaotique — l’équipe voit les tâches pour la première fois et ne peut pas les estimer, ce qui entraîne de l’imprévisibilité et des retards.

Le résultat du grooming est un ensemble de tâches prêtes pour le Sprint Planning : elles ont une description, des Acceptance Criteria, une estimation et respectent la Definition of Ready. Le Product Owner doit affiner les tâches par ordre de priorité : les plus proches du sprint actuel doivent être les plus détaillées. Les tâches pour 3–4 sprints à venir doivent rester au niveau d’épic. Technique de Progressive Refinement : plus une tâche est proche du sprint, plus sa description est détaillée. Pour les tâches du sprint actuel — affinement complet (AC, design, spécification API). Pour les tâches à 2 sprints — niveau story (user story sans détails d’implémentation). Pour les tâches à 3+ sprints — niveau épic (nom et valeur métier uniquement).

Definition of Ready : quand une tâche est prête pour le sprint

Definition of Ready (DoR) est une liste de critères qu’une tâche doit remplir avant d’être incluse dans le Sprint Backlog. Le DoR est un contrat entre le Product Owner et l’équipe : le PO garantit que toutes les informations nécessaires au développement sont disponibles, et l’équipe garantit qu’elle peut estimer et réaliser la tâche. Le DoR n’est pas universel — chaque équipe définit son propre ensemble de critères. Sans DoR, une tâche peut entrer dans un sprint avec des exigences floues, ce qui entraîne des reprises et des retards.

DoR typique pour le développement mobile : 1) Les Acceptance Criteria sont décrits (format Given-When-Then). 2) La maquette de design est prête dans Figma (pour les tâches UI) avec tous les états : default, loading, error, empty state. 3) La spécification API est approuvée (OpenAPI/Swagger, exemples de requêtes et réponses). 4) L’estimation en story points est disponible. 5) Les dépendances envers d’autres tâches sont identifiées. 6) La tâche ne dépend pas de composants externes non terminés. 7) Spécificités mobiles : versions cibles du système définies, nécessité d’un feature flag, prise en charge des anciens niveaux d’API.

Techniques d’estimation des tâches

Planning Poker est la technique d’estimation la plus populaire lors du grooming. Chaque développeur reçoit un jeu de cartes avec les nombres de Fibonacci (1, 2, 3, 5, 8, 13, 21). Le PO présente une tâche et l’explique. Après discussion, tout le monde montre sa carte simultanément. Si les estimations divergent considérablement (par exemple 3 et 13), les développeurs expliquent leur raisonnement et votent à nouveau. Les itérations se répètent jusqu’à ce qu’un consensus soit atteint. L’objectif du Planning Poker n’est pas une estimation précise, mais la révélation des différences de compréhension de la tâche.

T-Shirt Sizing est une technique simplifiée pour des estimations rapides : XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Elle convient pour le tri initial du backlog lorsqu’il y a beaucoup de tâches et que vous avez besoin d’un ordre de grandeur approximatif. Après le T-Shirt Sizing, une estimation plus précise via Planning Poker est effectuée pour les tâches du prochain sprint. Affinity Estimation est une technique de tri en groupe où les tâches sont disposées sur une table de la plus simple à la plus complexe sans utiliser de chiffres, puis regroupées en clusters, et chaque cluster reçoit une estimation.

Dans le développement mobile, l’estimation doit tenir compte de la complexité de la plateforme. Une tâche Android peut être estimée à 5 SP tandis que la même tâche pour iOS peut être à 3 SP (ou l’inverse). C’est normal : différentes plateformes ont une complexité d’implémentation différente. Conseil : estimez chaque plateforme séparément si l’équipe est multiplateforme. Utilisez une échelle relative : une tâche de base (par exemple, un écran avec du texte et un bouton) = 1 SP. Tout le reste est relatif à celle-ci. Selon Scrum.org (2025), après 3–4 sprints, la précision d’estimation de l’équipe atteint ± 20 % de la complexité réelle.

Décomposition : comment diviser les grandes tâches

Les tâches de plus de 8 SP doivent être décomposées en tâches plus petites. Les grandes tâches ne peuvent pas être terminées en un seul sprint, sont difficiles à estimer et ne donnent pas de sentiment de progression. Techniques de décomposition : diviser la tâche par couches horizontales (UI → ViewModel → Repository → Network/DB) ou par tranches verticales (fonctionnalité : un écran complet). La décomposition horizontale fonctionne mieux pour le développement mobile : Sous-tâche 1 — maquette UI (XML/Jetpack Compose/SwiftUI), Sous-tâche 2 — ViewModel + State, Sous-tâche 3 — Repository + Network, Sous-tâche 4 — Tests unitaires.

Décomposition verticale — diviser les user stories en histoires plus petites avec une valeur indépendante. Exemple : Epic « Panier d’achat » → Story 1 « Ajouter un article au panier », Story 2 « Afficher le panier », Story 3 « Supprimer un article du panier », Story 4 « Commander ». Chaque histoire a sa propre valeur métier et peut être publiée indépendamment. SPoK (Story Points on Kano) : classez les histoires par valeur métier (Must-have, Should-have, Could-have) et implémentez-les dans l’ordre de valeur.

Liste de contrôle de décomposition lors du grooming : 1) La tâche est-elle supérieure à 8 SP ? → Décomposer. 2) Les Acceptance Criteria sont-ils définis ? → Sinon, les ajouter. 3) Dépend-elle d’autres tâches ? → Identifier et documenter les dépendances. 4) Contient-elle de l’incertitude ? → Ajouter un Spike (recherche) avant la tâche principale. 5) Le design est-il nécessaire ? → Vérifier la disponibilité des maquettes. Règle INVEST : Independent (indépendante des autres), Negotiable (négociable), Valuable (précieuse pour le métier), Estimable (estimable), Small (petite), Testable (testable). Si une tâche ne respecte pas INVEST, elle n’est pas prête pour le sprint.

Processus de grooming : étape par étape

Étape 1 : Échauffement (5 minutes). Le Scrum Master rappelle à l’équipe l’objectif du grooming et le DoR. L’équipe regarde le tableau et le PO montre quelles tâches seront discutées. Étape 2 : Revue des tâches (30 minutes). Le PO présente séquentiellement les tâches de la fin du sprint actuel et du début du suivant. Pour chaque tâche : nom, description, Acceptance Criteria (le cas échéant), lien vers le design, spécification API. L’équipe pose des questions de clarification : « Y a-t-il une maquette pour l’état vide ? », « Quelle méthode HTTP ? », « Quel est le minimum deployment target iOS ? »

Étape 3 : Estimation (15 minutes). L’équipe estime la tâche via Planning Poker ou T-Shirt Sizing. Si l’écart est supérieur à 2 SP, ils discutent des raisons et votent à nouveau. Règle : si une tâche ne peut pas être estimée (exigences floues, pas de design), elle est renvoyée au PO pour affinement et reviendra au prochain grooming avec des clarifications. N’estimez pas les tâches comportant des inconnues — cela garantit des erreurs dans le sprint. Étape 4 : Enregistrement des résultats (10 minutes). Le PO enregistre les estimations dans Jira/Linear, met à jour la description de la tâche et définit les priorités.

Résultats du grooming : 3–7 tâches complètement préparées pour le Sprint Planning (avec DoR, estimation, design, API). Le PO met à jour le backlog : supprime les tâches obsolètes, fusionne les doublons et affine les priorités. Important : le grooming ne termine pas le travail du PO — entre les sessions de grooming, le PO doit préparer les tâches suivantes. Rythme recommandé : le PO prépare 3–4 tâches pour le grooming, et l’équipe les traite. S’il y a plus de 50 tâches dans le backlog, le PO doit effectuer une priorisation (MoSCoW ou Weighted Shortest Job First) avant le grooming.

Différences entre grooming et Sprint Planning

Le grooming est une préparation. Il n’y a pas d’engagement — la tâche est simplement clarifiée et estimée. Sprint Planning est un engagement. L’équipe sélectionne les tâches parmi celles préparées lors du grooming et s’engage à les réaliser pendant le sprint. Différences clés : le grooming n’est pas lié à un sprint spécifique (affinage du backlog dans son ensemble), il n’y a pas de Sprint Goal pendant le grooming, et le grooming peut avoir lieu à tout moment du sprint. Le Sprint Planning a lieu strictement au début du sprint et aboutit toujours à un Sprint Goal.

Lors du grooming, les tâches sont uniquement estimées, mais pas reprises dans le sprint. Lors du Planning, les tâches sont sélectionnées à partir du pool préparé. Sans grooming, le Sprint Planning dure 6 à 8 heures (au lieu de 4), car l’équipe voit les tâches pour la première fois et ne peut pas les estimer rapidement. Règle 80/20 : 80 % des tâches au Sprint Planning doivent être complètement préparées (avoir passé le grooming), 20 % peuvent être nouvelles (bugs urgents, hotfixes). Si plus de 20 % des tâches ne sont pas estimées au Planning, le grooming était insuffisant.

Erreurs fréquentes de grooming

Erreur 1 : grooming une fois par mois. L’équipe accumule les tâches de 3–4 sprints et essaie de tout affiner en 2 heures. Résultat : la moitié des tâches reste non estimée et le Planning prend toute la journée. Solution : le grooming doit être régulier — une fois par sprint, 60 minutes. S’il y a beaucoup de tâches, ajoutez un deuxième grooming au milieu du sprint. Il vaut mieux affiner peu de tâches en profondeur que beaucoup superficiellement. Rythme : 3–5 tâches par session de grooming, chacune avec une discussion et une estimation complètes.

Erreur 2 : estimation sans contexte. Le PO présente une tâche « Implémenter l’écran du panier » sans design, API ou AC. L’équipe estime « à vue d’œil » — 13 SP. Lors du Planning, il s’avère que c’est en réalité 5 SP (parce que l’écran est simple). Solution : une tâche n’est pas estimée si elle n’a pas de design ou d’API. Le PO doit préparer les matériaux avant le grooming. Règle : « Pas de maquette, pas d’estimation ». Exception : les tâches Spike — recherche d’incertitude, elles sont estimées séparément sans design (2–5 SP selon la complexité de la recherche).

Erreur 3 : le grooming se transforme en Planning. L’équipe commence à attribuer les tâches aux personnes et à discuter de qui fera quoi. Solution : rappeler que le grooming sert à clarifier, pas à attribuer. L’attribution se fait lors du Daily après le début du sprint. Le grooming répond « quoi faire ? », le Planning répond « quand le faire ? », le Daily répond « qui le fait ? ». Mélanger ces questions dans une seule réunion réduit l’efficacité de chacune. Le Scrum Master doit interrompre les discussions de type Planning et recentrer l’attention sur la clarification de la tâche.

Erreur 4 : ignorer la dette technique. Lors du grooming, seules les nouvelles fonctionnalités sont discutées ; les tâches techniques sont ignorées. Après 3–4 sprints, la dette technique s’accumule à un niveau critique. Solution : à chaque grooming, au moins 1 tâche technique doit être estimée. Proportion : pour 3 fonctionnalités → 1 tâche technique. Utilisez la métrique Tech Debt Ratio : rapport des tâches techniques aux tâches fonctionnelles dans un sprint. Valeur cible : 0,25–0,3 (25–30 % du temps consacré à la dette technique). Si le ratio est inférieur à 0,2, la vélocité de développement diminuera dans les sprints suivants.