Animer un Sprint Planning : Guide et Astuces

Scénarios :

• Le Product Owner expose l’objectif global du projet.
• En collaboration avec le Business Analyst, le Product Owner détaille clairement les exigences de bouche à oreille.
• Les développeurs posent des questions pour éclaircir les points obscurs.
• Les développeurs :
  • remettent en question la solution proposée, apportant un regard critique.
  • évaluent la faisabilité du projet et proposent, le cas échéant, un Proof of Concept (POC).
  • reévaluent les Story Points si nécessaire.
• Le Quality Analyst initie la réflexion sur les besoins et élabore une stratégie de test appropriée.

Scénarios :

• Découper absolument quand :
  • Les développeurs ne peuvent pas estimer car trop complexe
  • Ca ne rentre pas dans un Sprint
• Découper éventuellement pour mieux maîtriser le périmètre (plus les unités sont petites, plus elles sont contrôlables)
• Les découpages sont faits en concertation avec le Product Owner

Comment réaliser la découpe ? En utilisant le modèle INVEST, les User Stories doivent présenter les caractéristiques suivantes :

• INDÉPENDANTES : elles doivent être livrables de manière indépendante.
• NÉGOCIABLES : il doit être possible de les supprimer sans impacter l’ensemble de la fonctionnalité.
• VALORISANTES : elles doivent apporter une valeur métier tangible.
• ESTIMABLES : leur effort doit être mesurable.
• PETITES (SMALL): plus elles sont petites, plus elles sont gérables.
• TESTABLES : des scénarios de tests doivent pouvoir démontrer que la User Story est complète.

Une User Story efficace doit pouvoir être formulée en une phrase utilisant le format “En tant que [rôle], je dois pouvoir [action], afin de [objectif]“

Attention, ce n’est pas suffisant !

Par exemple : en tant qu’ un utilisateur, je dois pouvoir chercher selon des dates flexibles, afin de trouver les vols qui me conviennent.

• Peut être encore découpée en
  • … ” n jours entre x et y ” …
  • … ” Un weekend pendant un mois donné “…
  • … ” +/- n jours entre x et y “…

Après avoir identifié les User Stories, les développeurs :

• Font un brainstorming sur les Tasks (conception, développement … etc) de chaque User Story.
• Une tâche doit être claire pour tout le monde. Une conception technique peut être abordée pour les tâches complexes.
• Déterminent éventuellement les refactorings nécessaires pour chaque User Story.
• Remontent les risques techniques et proposent des plans pour mitiger les risques.

Les estimations sont faites pour les User Stories qui ont été discutées lors des phases précédentes. Cela signifie que l’équipe se penche sur les tâches qu’elle prévoit de réaliser pendant le sprint.

Selon les cas, l’estimation en Story Points a déjà été faite :

• Avant le Sprint Planning (pendant les Sprint Review)
• Ou pendant la phase d’exploration du Sprint Planning

Lorsque nous parlons d’unités d’estimation, nous pouvons utiliser deux principales :

• Le Story Point est utilisé pour estimer la complexité des User Stories. Cela nous aide à comprendre à quel point une tâche peut être difficile.
• Le Jour Homme est utilisé pour estimer le temps nécessaire pour effectuer des tâches de développement ou d’autres activités plus détaillées. Cela nous aide à prévoir combien de temps il faudra pour terminer des sous-tâches spécifiques liées aux User Stories.

Étapes:

• Réviser la capacité de l’équipe en faisant attention aux congés, jours fériés…
• Prendre les Users Stories dans l’ordre de priorité jusqu’à arriver à la vélocité cible acceptée par tous les acteurs.
• Ces Users Stories constitueront le Sprint Backlog.

Le Product Owner ne force pas l’équipe à prendre plus de User Stories que ce que l’équipe peut réellement accomplir pendant le sprint.

Cela garantit que les problèmes techniques sont abordés avant de s’engager dans la mise en œuvre, minimisant ainsi les risques et favorisant une exécution plus fluide des tâches.

Pour la Scrum Team, la vélocité est la capacité en Story Points à produire pendant un Sprint

Ce qu’est la vélocité

• Une valeur déduite : Elle est calculée en se basant sur la quantité de travail (généralement en Story Points) que l’équipe a réussi à terminer lors de chaque Sprint. Elle est mise à jour après la clôture de chaque Sprint.
• Utilisée pour construire des roadmaps et des plannings : La vélocité permet d’estimer combien de travail une équipe peut accomplir dans les futurs Sprints. Cela aide à planifier et à prioriser les User Stories ou les tâches à inclure dans les prochains développements.

Ce que n’est pas la vélocité

• La productivité : Elle ne mesure pas la performance individuelle des membres de l’équipe, mais plutôt la capacité collective de l’équipe à livrer des éléments pendant un Sprint.
• Un moyen de juger l’équipe : Elle ne doit pas être utilisée pour évaluer la qualité du travail de l’équipe, mais plutôt comme un outil de planification.
• Un moyen de comparer les équipes : Chaque équipe a sa propre vélocité basée sur ses capacités, son unité d’estimation et sa façon de travailler, ce qui la rend non comparable à d’autres équipes.
• Un moyen d’influencer l’engagement de l’équipe : La vélocité n’est pas un indicateur pour pousser l’équipe à travailler plus rapidement, mais plutôt un moyen d’estimer la capacité de l’équipe de manière réaliste. L’engagement de l’équipe doit être basé sur une compréhension claire des objectifs et des priorités du Sprint.