Sprint planning virtuel

Le sprint planning virtuel en visioconférence se déroule généralement de deux manières. Soit le product owner parle pendant une heure pendant que les développeurs restent en sourdine, soit tout le monde estime en tapant un chiffre dans le chat en espérant que ça suffise. Les vraies discussions — « Quelles sont les inconnues techniques ? » « Avons-nous déjà construit quelque chose de similaire ? » — n'ont jamais lieu, faute d'espace pour les accueillir.

Sur Flat.social, le sprint planning se divise en conversations qui produisent réellement de bonnes estimations. Le product owner présente les stories sur la scène de la salle de conférence, puis les développeurs se répartissent dans des zones d'estimation — des salles isolées acoustiquement avec des tableaux blancs. Des groupes de 3-4 personnes esquissent des architectures, cartographient des flux de données et débattent de la complexité grâce à l'audio spatial. Le tableau blanc capture des risques que la discussion verbale ne révèle pas.

Après l'estimation, l'équipe se retrouve pour réconcilier les différences et s'engager sur l'objectif du sprint. Les écarts entre les groupes déclenchent les discussions les plus précieuses. Le tableau de sprint est affiché sur un billboard visible par tous en temps réel. Le planning devient une session de travail, pas une réunion.

Conseils pour les Scrum Masters

Organiser un sprint planning qui génère un vrai engagement :

1. Limiter le temps de présentation du backlog. Accordez 2-3 minutes par story au product owner dans la salle de conférence. Si une story nécessite plus d'explications, elle n'est pas prête pour le planning. Renvoyez-la au refinement.

2. Composer les groupes d'estimation avec intention. Mélangez développeurs seniors et juniors dans chaque zone. Les juniors posent des questions qui révèlent une complexité cachée. Les seniors apportent un contexte qui améliore les estimations.

3. Utiliser les tableaux blancs pour chaque story. Même les stories simples bénéficient d'une esquisse rapide de l'architecture. Prenez-en l'habitude. Les groupes qui dessinent leur approche sur le tableau blanc détectent des risques que la discussion verbale ne révèle pas.

4. Laisser les écarts guider la discussion. Quand les groupes reviennent avec des estimations différentes, ne faites pas la moyenne. Demandez à chaque groupe d'expliquer son raisonnement. L'écart entre un 3 et un 8, c'est là que les meilleures conversations techniques ont lieu.

5. Mettre à jour le billboard du sprint en direct. Au fur et à mesure que les stories sont estimées et validées, mettez à jour le billboard en temps réel. Voir le sprint prendre forme crée un sentiment de responsabilité partagée.

Conseils pour les développeurs

Pour que vos estimations comptent :

Esquissez avant d'estimer. Prenez le tableau blanc de votre zone d'estimation et dessinez le flux de données ou le diagramme de composants. La planification visuelle révèle des dépendances et des cas limites qui ne semblent évidents qu'une fois dessinés.

Exprimez les inconnues. Si vous ne comprenez pas une story, dites-le. « Je ne sais pas comment fonctionne la couche d'authentification ici » a plus de valeur qu'une estimation approximative. Les inconnues doivent augmenter l'estimation, pas être ignorées.

Allez voir le product owner. Si votre groupe d'estimation a une question, n'attendez pas la phase de réconciliation. Approchez-vous sur le sol spatial et posez votre question grâce à l'audio de proximité. Les clarifications rapides font gagner du temps.

Prenez en charge les stories que vous avez estimées. Vous les comprenez le mieux. Portez-vous volontaire pour le travail que votre groupe a discuté sur le tableau blanc. Le contexte accumulé pendant l'estimation permet de démarrer le sprint plus vite.