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.