1

1. Méthodologies de
développement
d'applications
Planification des tâches avec SCRUM
Alpha-Oumar Sow
alpha.oumar.sow@colval.qc.ca

2. Rappel
https://wiki.sfeir.com/agilite/scrum/equipe-scrum/nexus/

3. Rappel

4. La Planification
en SCRUM

5. Pourquoi planifier?
Planification est l’activité qui consiste à
déterminer et à ordonnancer les tâches du
projet, à estimer leurs charges et à déterminer
les ressources nécessaires à leur réalisation.
Rendez-vous de planification dans SCRUM:
• Release Planning
• Sprint Planning

6. Planification d’une release :
D’abord, c’est quoi une release?
• Une version de produit est une « release » et
a un backlog produit (product backlog).
• Les releases sont dérivées du Product
Roadmap (feuille de route de développement
du produit)
• Une « release » contient plusieurs sprints
(itérations)
• Idéalement une release dure de 1 à 3 mois
avec un livrable bien défini.
• Le nombre de sprint nécessaires pour livrer
une release est obtenu à partir de la taille du
release backlog et de la vélocité de l’équipe.

7. Planification d’une release :

8. Planification d’une release :
Qui sont impliqués ? Et quelles sont leurs tâches?
Clients/Product Owner
• Définir le Backlog de la release
• Définir les priorités des user stories
• Placer les user stories dans des itérations selon les
priorités techniques et d’affaire.
• Etc.
Développeurs
• Estimer les user stories
• Relever les risques
• Établir la vélocité (capacité de développement de l’équipe)
• Etc.

9. Planification d’une release :
Rebuild the plan
• Un plan de release peut être modifié pour différentes raisons:
• Changement dans la priorité des user stories (Adaptation)
• User stories peuvent être déplacées d’une itération à l’autre selon la volonté du Product
Owner ou les développeurs (stories techniques).
• L’ajout de nouvelles user stories
• La possibilité d’ajout de nouveau besoin durant le développement est l’un des principes
fondamentaux de la démarche Agile.
• Story ‘blows-up’ à cause de difficultés techniques ou bien la portée
• Variation dans la vélocité de l’équipe

10. Planification d’une release : Exemples

11. Planification d’un Sprint
• L'objectif principal de la réunion de planification
de sprint est de repartir avec deux choses :
• But du sprint : convenir de ce qui sera livré à
la fin du sprint.
• Backlog de sprint : ensemble de User Stories
priorisées, les améliorations, les bugs, les
tâches et les sous-tâches pour le prochain
sprint.
• Durée moyenne : 2h

12. Définir un but pour le Sprint
• Un but de Sprint montre le résultat souhaité d'une itération. Il doit être défini avant le début de
l’itération. Ce but est partagé par toute l’équipe, afin qu’elle puisse se concentrer pour l’atteindre.
• Un but de sprint est une brève description en une ou deux phrases de ce que l'équipe prévoit
d'accomplir pendant le sprint. Il est rédigé en collaboration par l'équipe et le propriétaire du
produit.
Exemples : Voici des buts de sprint typiques pour une application de commerce électronique:
• Ajouter, supprimer et mettre à jour les quantités pour le panier.
• Développer le processus de paiement : payer une commande, choisir l'expédition, commander
un emballage cadeau.

13. Définir un but d’itération en 4 étapes :
Sprint Goal Template
Le but de sprint est généralement défini lors du Sprint
Planning à travers les étapes suivantes :
1. Le Product Owner présente les éléments de
backlog prioritaires à l'équipe.
2. L'équipe discute et comprend le travail de ce
Sprint.
3. L'équipe prévoit et s'engage sur les éléments
qui peuvent être réalisés.
4. L'équipe crée un but pour ce sprint.
https://www.visual-paradigm.com/scrum/write-sprint-goal/

14. Le contrôle
en SCRUM

15. Points de contrôle dans SCRUM
Contrôle de la progression
• Release Review
• Sprint Review
• Daily Standup
Contrôle de la qualité
• Qualité du processus (DEV TEAM)
Sprint Rétrospective
Contrôle des grandeurs vélocité/capacité de l’équipe
Burn-up/Burn-down charts
• Qualité du produit
Acceptance Criteria (Sprint Planning)
DOR (Definition Of Ready)
DOD (Definition Of Done)

16. Definition Of Ready (DOR)
• Le résultat final du Grooming est une
réorganisation des items du Product Backlog
(PBI). Les PBI les plus prioritaire sont placés en
en haut du Backlog et sont prêts à faire partie
du prochain sprint.
• Les équipes SCRUM peuvent s’entendre sur
une liste de conditions qui permettent de
décider si un PBI est prêt à être réalisé (DOR).
• Ci-contre un ex. d’un document DOR
https://innolution.com/essential-scrum/table-of-contents/chapter-6-product-backlog

17. Definition Of Ready (DOR):
Steps in developing Definition of Ready
The Definition of Ready should not stay fixed. Rather, it should grow and develop as the team
evolves in terms of-
• The working pace
• The understanding of ‘what’ makes a good user story.
https://www.knowledgehut.com/tutorials/scrum-tutorial/definition-of-ready

18. Notion du ‘fini’(« Done»)
• Objectif : fixer le niveau de qualité attendu
• Une condition pour dire qu'une user story est finie.
• La notion de « Done » implique plusieurs couches :
technique, métiers, IHM, documentation, etc.
• La notion du « Done » doit être partagée et connue de
tous.
• Pour une équipe, la notion « done » est généralement
transversale à plusieurs choses différentes.
• Cette notion est très liée à la notion de test (unitaire et
d'acceptation)

19. Notion du ‘fini’(« done»)
Grille de définition du ‘fini’
• La grille ci-contre fournie des conditions qui
pourraient définir la notion du ‘fini’ pour une
user-story, sprint, ou une release.
• DOD peut être rebuild lors de la réunion
Sprint Retrospective

20. Definition of Done (DoD) :
Exemples (1/3)
DoD d’une user-story
• All tasks complete
• All code is checked in
• All developer tests pass
• All acceptance tests pass
• Integration tested
• Performance tested
• Documented (just enough)
• Product Owner accepted
DoD d’un sprint
• Sprint backlog is complete
• Performance tested
• Defects fixed or postponed

21. Definition of Done (DoD) :
Exemples (2/3)
1. Peer Reviewed : la User Story a été revue par l’autre membre du binôme.
2. 80 % Code Coverage : le code écrit pour implémenter la User Story a été couvert par des
tests avec une couverture minimale de 80 %.
3. Follow Code Maintainability Guidelines : respecte les recommandations concernant la qualité
et la maintenabilité du code.
4. Follow Coding Rules : respecte les règles concernant la manière de développer en équipe.
Livre : Julien Plée, Conduite de projets agiles - Management alternatif dans une équipe de développement agile, Éditions ENI, 2015

22. Definition of Done (DoD) :
Exemples (3/3)
• Performance tuned
• Security validation passes
• Disaster recovery plan tested

23. Acceptance Criteria : Rappel
Alors qu'une User Story est délibérément vague pour permettre à l'équipe de décider des détails
précis de la façon dont quelque chose sera construit, les critères d'acceptation sont les détails
précis. Ils sont uniques à chaque User Story.
Les objectifs des critères d'acceptation sont:
• Clarifier ce que l'équipe doit construire avant de commencer à travailler.
• Assurer que tout le monde a une compréhension commune du problème.
• Aider les membres de l'équipe à savoir quand ils doivent cesser de travailler sur une User
Story. Ceci est différent de «DOD», car ils peuvent avoir satisfait aux critères d'acceptation
mais pas tout vérifié par rapport à «DOD».
• Aider à vérifier l'histoire via des tests automatisés.

24. Definition of Done vs Acceptance Criteria
• Alors, que les critères d'acceptation sont uniques pour
chaque user story, les critères de Done / Fini sont un
ensemble de règles qui s'appliquent à toutes les user
story dans un sprint donné
• La définition de fini (DoD) est établie par l'équipe de
développement, tandis que les critères d'acceptation
sont préparés par le propriétaire du produit (PO).

25. Contrôle de la vélocité
La vélocité est la quantité de travail qu'une équipe
SCRUM peut accomplir sur une certaine période de
temps. La vitesse de SCRUM peut être calculée à
plusieurs niveaux:
• Vitesse au niveau du sprint : combien de points
d'histoire l'équipe parvient-elle à terminer par
sprint ?
• Vélocité au niveau de Epic ou Release : le
Burndown Chart de l’Épic ou de la Release
permet de suivre dans quelle mesure l’objectif
prévus (Nombre de Story Points) de l’Épic ou de
la Release a été achevée.

26. Contrôle de la vélocité
• La régularité de la courbe de la vélocité est signe du respect de la qualité, ou de la stabilité de
l'environnement (et la stabilité de l'environnement mène au respect de la qualité)
• Les pics dans la courbe indiquent des problèmes d’estimation des User Stories/Tasks
(complexité des user stories mal comprise)

27. Problèmes avec la vélocité
• Fixer un objectif pour la vélocité : ceci peut être trompeur, car les estimations des Story Points sont subjectives.
• Prévoir une vitesse maximale instantanée : l'équipe doit apprendre à coopérer et à répartir le travail entre les
membres de l'équipe, à comprendre la complexité des tâches et à s'adapter aux dépendances et aux exigences
extérieures avant d’atteindre la vélocité attendue.
• Travail non décomposé en blocs de granularité approprié : le problème commence lorsque les équipes ne
décomposent pas les éléments (Epics, User Stories) avec une granularité suffisante. On observe ce symptôme
sur le graphique Velocity Burndown Chart, lorsque le graphe chute brusquement au milieu d'un sprint.
• Temps mort : pour être efficace, une équipe SCRUM a besoin d'un peu de «temps mort» ou d'inactivité intégré
à ses sprints. Une équipe sans temps mort devient «occupée» et trop concentrée sur les objectifs individuels, ce
qui nuit à leur vitesse à long terme. Une règle de base courante consiste à prévoir une marge de 20% pour la
communication et la résolution des problèmes urgents ou des interruptions.
• Dette technique et bogues connus : bien que ces éléments n'ajoutent pas de nouvelles fonctionnalités pour
l’utilisateur, ils représentent une valeur tangible sous la forme d'une qualité supérieure du produit.
https://www.sealights.io/sprint-velocity/scrum-velocity-5-things-that-can-go-wrong/

28. Progression de la vélocité :
Burndown/Burnup charts
• Burndown de release: basé sur les story points
• Burndown de sprint: basé sur les heures, points affectés aux
tâches ou encore le nombre de tâches restantes.
Les burndown/burnup sont visibles par tous les stakeholders

29. Atelier de rétrospective : Faits saillants
• La réunion la plus sous-estimée et la plus sous-utilisée de toutes les cérémonies de SCRUM.
• But : améliorer le processus SCRUM
• Dure en général de 15 à 30 minutes
• Fait à la fin de chaque sprint
• Revue de la vélocité réelle de l’équipe
• Analyse des causes du succès et de l’échec
• Toute l'équipe participe
• ScrumMaster
• Equipe
• Éventuellement les clients et autres intervenants

30. Atelier de rétrospective :
Run Sprint Retrospective
Toute l'équipe collecte du feedback et discute sur ce qu'elle aimerait:
• Ce qui c'est bien passé
• Ce qui s'est mal passé
• Qu'est-ce qu'on peut améliorer
Outils :
• 5 Why’s
• Sailboat
https://www.atlassian.com/blog/jira-software/5-fun-sprint-retrospective-ideas-templates

31. Atelier de rétrospective : Exemples de 5 Why’s
You are on your way home from work and your car stops
1. Why did your car stop? Because it ran out of gas.
2. Why did it run out of gas? Because I didn’t buy any
gas on my way to work.
3. Why didn’t you buy any gas this morning? Because
I didn’t have any money.
4. Why didn’t you have any money? Because I lost it
all last night in a poker game.
5. Why you lose at poker ? Because I am tournament
poker player
Solution: ?
Le Washington Monument se désintégrait :
1. Pourquoi ? Utilisation de produits chimiques agressifs.
2. Pourquoi ? Pour nettoyer les excréments de pigeon.
3. Pourquoi autant de pigeons ? Ils mangent des araignées et
il y a beaucoup d'araignées au monument.
4. Pourquoi autant d'araignées ? Elles mangent des
moucherons et il y a beaucoup de moucherons au
monument.
5. Pourquoi autant de moucherons ? Ils sont attirés par la
lumière à la tombée de la nuit.
Solution : Allumer les lumières à un moment plus tardif.

32. Atelier de rétrospective : SailBoat idea
1. Montrez à l’équipe l’image d’un voilier poussé par le vent, ralenti par une ancre et entouré de
rochers.
2. Expliquez que, comme ce voilier, un sprint avance ou ralentit selon plusieurs facteurs.
3. La terre représente l’objectif, le vent ce qui pousse l’équipe, l’ancre ce qui freine, et les rochers
les risques.
4. Écrivez l’objectif de l’équipe. Demandez à chacun ce qui les pousse, les freine et les met en
danger.
5. Chaque membre note ses idées sur un post-it, les explique et les regroupe avec l’équipe.
6. Identifiez ensemble le risque principal et le problème prioritaire à traiter. Si besoin, organisez
un vote.
https://www.atlassian.com/blog/jira-software/5-fun-sprint-retrospective-ideas-templates

33. Sprint Review vs Sprint Retrospective

34. Les valeurs SCRUM

35. 1. User Goal
2. Activity/Theme/Feature
3. Epic
4. User Story
5. Task
5 Requirement Spec.
Framework SCRUM : 5x5
1. Product Owner (Primary)
2. Scrum Master (Primary)
3. Dev Team (Primary role)
• Team Member
• Team Lead
• Architecture Owner
4. Stakeholder (Supporting)
5. Agile Coach (Supporting)
5 Roles
• Story Map Workshop
• Learning loop :
• Sprint Planning
• Sprint Review
• Sprint Retrospective
• Daily Stand-up
5 Ceremonials
1. Backlogs (Release/Sprint)
2. Release plan
3. DOD (Story/Sprint/Release)
4. DOR
5. Burn up/down Chart
5 Artefacts
1. Commitment
2. Focus
3. Courage
4. Openness
5. Respect
5 Values

36. SCRUM https://wiki.sfeir.com/agilite/scrum/equipe-scrum/nexus/

37. Références
https://www.visual-
paradigm.com/scrum/write-sprint-goal/
https://www.atlassian.com/blog/jira-
software/5-fun-sprint-retrospective-
ideas-templates
https://www.sealights.io/sprint-
velocity/scrum-velocity-5-things-that-
can-go-wrong/
https://www.visual-paradigm.com/scrum/