Sprint Planning
Transcription
Sprint Planning
Sprint N-1 Sprint N Sprint Planning Vérification estimations initiales Pour les premiers items : Instanciation d’un Tasks Pattern Estimation des tâches en heures Prépa N Product Backlog Dev N-1 Sprint Backlog DEV N Release Planning (review) Démarrage d’un Item (US, TS, DEFECT) Estimation/ré-estimation des user-stories du Product Backlog Business value & Complexité Instanciation d’un Tasks Pattern Estimation des tâches en heures Planning Poker en points Déroulement : planning de Sprint sprint Planning J1 J2 J3 J4 J5 J6 J 8 J 9 J 10 Revue Retro spective A chaque début de Sprint Tous les acteurs présents ½ journée ou 1 journée max But : Prioriser les user-stories Explications du product owner Estimations en commun Choix du contenu du prochain sprint Toute l’équipe comprend et partage l’objectif commun Page 2 Déroulement : Daily Scrum sprint Planning J1 J2 J3 J4 J5 J6 J 8 J 9 J 10 Revue Retro spective Chaque jour Equipe + Scrum master, éventuellement product owner 15 min max Chaque membre de l’équipe répond de manière concise à 3 (ou 4) questions - Ce que j’ai fait hier - Ce que je vais faire aujourd’hui - Mes problèmes (on ne les résout pendant le daily scrum) - Mes estimations sont-elles toujours valides (éventuellement) C’est un point de synchro Cela ne doit pas être vécu comme un reporting Page 3 Déroulement : Auto-organisation Les membres de l’équipe choisissent leurs tâches Ils forment eux-mêmes les éventuels binômes Ils sont dans la même pièce, le scrum master aussi Il n’y a pas de rôle prédéfini, c’est l’équipe qui s’auto-affecte les rôles en fonction des sujets à traiter Le Scrum master veille au bon déroulement et arbitre si nécessaire Le Scrum master laisse l’équipe s’auto-organiser Il oriente l’équipe si nécessaire Page 4 Déroulement : Revue de Sprint sprint Planning J1 J2 J3 J4 J5 J6 J 8 J 9 J 10 Revue Retro spective A la fin de chaque Sprint Equipe + Scrum master, product owner + invités ½ journée invités L’équipe réalise une démonstration des user-stories développées Le product owner les a probablement réceptionnées avant cette réunion Les user-stories qui ne sont pas « finies-finies » valent 0 Le product owner entérine les user-stories acceptées Suite au bilan du Sprint, les orientations du prochain sprint sont déterminées en vue de préparer le prochain Sprint Planning C’est une démonstration – Ce ne doit pas être vécu comme une recette L’équipe partage son travail Les suites à donner sont décidées en off après la démo Page 5 Déroulement : Retrospective sprint Planning J1 J2 J3 J4 J5 J6 J 8 J 9 J 10 Revue Retro spective A chaque fin de Sprint Equipe + Scrum master (+animateur) ½ journée max L’équipe examine -Ce qu’il faut conserver -Ce qu’il faut améliorer -Ce qu’il faut supprimer Arriver à un plan d’actions accepté par tous Attention aux dérives qui conduisent à la perte d’agilité Mettre à jour la documentation de management (PQP) si nécessaire NE JAMAIS ARRETER LES RETROSPECTIVES Page 6 Check-list QUOTIDIENNE des membres de l’équipe • • • • Mes User-stories et tâches sont à jour dans le taskboard J’ai mis à jour le backlog Je participe au daily scrum (9h30) J’ai éventuellement remonté des problèmes et idées sur le board • J’ai fait un point sur les user-stories dont je suis owner (avancement, documents, Validation de la user-story « DoD ») • J’indique la qualité de la journée que j’ai passée par un code couleur : vert, jaune, orange, rouge Check-list QUOTIDIENNE du Scrum Master • • • • • • J’anime le Daily Scrum Je vérifie que le Taskboard est à jour Je vérifie que le Backlog est à jour Je totalise des points en ToDO, In Progress et Done Je mets à jour le sprint burndown chart Je contribue à résoudre les problèmes remontés lors du Daily scrum ou affichés sur le board • Je m’assure du respect de la méthode Identified 2 Planned & Estimated 3 Defect or change request 1 To do Cycle de vie d’une US Plusieurs DONE -> Différentes représentations du RAF Raf Story pts In Progress < 5 jours Done (team / PO) Done (Acceptance) 4 Done (Mutuelle) Maintenance Raf Story pts DoD d’une US (Definition Of Done) • Le code source de l’US associé a été mis en gestion de configuration • L’US a été testée par au moins de 1 membre de l’équipe sans anomalie détectée • Le document de synthèse de la solution technique a été validée par le PO • Le product owner ou le US Owner si différent accepte la US Release Planning • Objectif : préparer le product backlog pour le Sprint 1 Définir les user stories de référence Construire la roadmap prévisionnelle du projet Evaluer la valeur métier et la complexité des user stories Pattern de tâches • Cadrage fonctionnel et technique de la solution envisagée • Intégration IHM • Développement et Tests unitaires • Rédaction d’une synthèse technique de la solution • Intégration et tests d’assemblage • Validation PO.