Page 1 sur 16

Formation pso via YouTube

SCRUM GUIDE
 Scrum guide EP 1 : https://www.youtube.com/watch?v=53Me6CvtSKM
 Scrum guide EP2 : https://www.youtube.com/watch?v=jFrVH2XNC3k
 Scrum guide EP 3 : https://www.youtube.com/watch?v=QqyGXNJ-ZTE
 Scrum guide EP 4 : https://www.youtube.com/watch?v=_pTS7XBJ2RY
 Scrum guide EP 5 : https://www.youtube.com/watch?v=s83QwyaklYI
 Scrum guide EP 6 : https://www.youtube.com/watch?v=IQAlAlTjbgc
 Scrum guide EP 7: https://www.youtube.com/watch?
v=IQAlAlTjbgc&list=PL9Q_Ei1JWJ4f5VcugVY84ipKEOfsPvphG&index=9
 Scrum guide EP 8: https://www.youtube.com/watch?
v=5zB98oIB82M&list=PL9Q_Ei1JWJ4f5VcugVY84ipKEOfsPvphG&index=11
 Scrum guide EP 9: https://www.youtube.com/watch?
v=MrNiTFgMbqA&list=PL9Q_Ei1JWJ4f5VcugVY84ipKEOfsPvphG&index=12

Mindset AGILE / Roue de l’agilité

Page 1 sur 16
 Page 2 sur 16

Iron triangle :

En agilité le scope est variable mais permet d’avoir des couts et temps de réalisation fixes.

Définition de scrum :

Scrum n’est pas une méthode, c’est un cadre léger.

Scrum est un Framework d’agilité qui a pour objectif d’affronter des problèmes et savoir y faire face
tout en adaptant sa façon de faire. Scrum prend une direction totalement opposée de ce que l’on
peut voir sur les méthodes en cycle en V ou autres méthodes en waterfall. Le scrum n’est pas un mini
cycle en V (pour rappel ci-dessous comment il se présente) :

Scrum ce n’est pas un cycle en V, comment ça se passe alors ?

Les utilisateurs/clients vont expliquer ce qui a de la valeur pour eux.

Le Product Owner va gérer la partie Product backlog puis une fois que c’est fait, les développeurs
vont s’occuper de la partie delivery.

Les cercles montrent que le travail est en harmonie entre les différentes acteurs scrum. Le product
owner n’est pas au-dessus des développeurs. Tout le monde travaille en collaboration.

Scrum est un framewok léger à alimenter de pratiques agiles.

Scrum est un cadre léger qui nous dit quelle est l’enveloppe à respecter mais ne nous dit pas
comment faire chacune des choses. C’est l’équipe qui définit ce qu’il y a dans l’enveloppe.

Page 2 sur 16
 Page 3 sur 16

CE QUE DEFINIT SCRUM :

Les itérations (Sprint)
Il définit les SPRINT’s composés de 4 cérémonies différentes : voir plus bas.

En scrum, on travaille en petites itérations de 2 à 4 semaines. Ces itérations ont le nom de SPRINT. La
majorité des équipes font 2 à 3 semaines.

On reste sur le même nombre de semaines sur chaque sprint.

Ces sprints sont rythmés : on commence par la même cérémonie et on finit le sprint par la même
cérémonie.

Les événements SCRUM

Ils sont tous time boxé, ne peuvent pas être écourtés ou prolongés, peuvent être clôturés une fois
l’objectif de l’événement atteint.

Chaque événement est une occasion formelle d’inspecter et d’adapter et sont conçus pour
permettre la transparence également.

ATTENTION : le sprint n’est pas adaptable sa durée est fixe. On définit une durée et on s’y tient.

Rajouter d’autres cérémonies n’est pas interdit en scrum mais ne doivent pas faire gaspiller du
temps.

- SPRINT :
o C’est le cœur du scrum
o A une durée d’un mois calendaire, voire moins. Si la durée est trop longue, le risque
et la complexité du sprint augmentent. Cette durée (d’un mois max) permet la
prédictibilité en assurant l’inspection et l’adaptation
o Permet de créer une release (une version d’un incrément produit « DONE »
potentiellement publiable)
o Un nouveau sprint commence immédiatement après la fin du précédent
o L’objectif du sprint est fixe ; les changements qui le remettent en cause ne sont pas
permis ;
o Les objectifs de qualité sont maintenus et jamais revus à la baisse ;
o Le périmètre ( ?) peut être clarifié et renégocié entre le Product Owner et l’équipe
de développement selon ce que l’équipe Scrum apprend
o Chaque Sprint a un objectif de ce qui doit être construit, une conception (design) et
un plan flexible qui guidera la construction, le travail lui-même et l’incrément produit
résultant

Page 3 sur 16
 Page 4 sur 16

 Contrairement aux méthodes cycles en V ou waterfall, scrum ne remet en aucun cas

en cause la qualité
- Annulation d’un sprint
o Seul le PO peut annuler un sprint en cours, avant son échéance sous l’influence des
parties prenantes (métier, scrum master, dév…)
o Raisons d’annulation :
 Objectif du sprint devient obsolète en raison d’un changement de direction
de l’organisation par exemple pour ne pas que les dév développent des
choses obsolètes
 S’il n’a plus de sens compte tenu d’une circonstance donnée
o Les éléments « DONE » sont alors examinés et s’ils sont potentiellement publiable, le
PO les accepte généralement.
o Les éléments inachevés sont remis sur la backlog produit et sont de nouveau estimés
o Le prochain sprint est relancé le jour définit normalement pour le commencer (si
sprint annulé un jeudi alors qu’un nouveau sprint est relancé un vendredi, on
attendra le vendredi pour commencer le nouveau sprint).
- Les cérémonies scrum :

Les sprints commencent toujours par :

1- Le SPRINT PLANNING :

Cérémonie qui se fait en début de chaque sprint.

 Vidéo complète sur le sprint planning :https://www.youtube.com/watch?v=EUkvdB_5VdI

 Vidéo objectif du sprint : https://www.youtube.com/watch?v=BfIsZcbB5XQ (voir vidéo
pour plus d’informations sur le sprint planning)
 OBJECTIF du sprint planning : permet de planifier le travail à réaliser sur le sprint et permet
de définir l’objectif du sprint (sprint GOAL).
 Le plan est défini par l’ensemble des membres de l’équipe Scrum
 Dure au maximum 8h pour un sprint d’un mois, moins de temps pour un sprint plus court. Il
est conseillé de ne pas dépasser 2h.
 Le scrum master veille à apprendre à l’équipe à respecter le timebox fixé
 L’objectif du sprint est fixe, mais le scope reste variable : ça veut dire que l’on peut rajouter
ou décommissionner des ITEMS en cours de sprint. Voir cette vidéo à ce sujet :
https://www.youtube.com/watch?v=RB4Fk3zT2RE
 C’est Le Product Owner qui est le maître de cérémonie. Le Scrum Master sera plutôt celui qui
va seconder le Product Owner pour intervenir en cas de besoin.

Que faire durant un sprint :

 La Planification du Sprint répond aux questions suivantes :

o Qu’est qui peut être livré ?
o Comment effectuer le travail à livrer et le travail nécessaire ? : le découpage
technique n’est pas la seule chose à aborder durant la planification du sprint, mais il
faut également aborder le COMMENT on va livrer
 Durant le sprint planning, le PO explique l’objectif du sprint qui doit être concrétisé, ainsi que
les éléments du backlog produit qui permettront de l’atteindre.
 Les éléments permettant de commencer un sprint planning :
o Le backlog produit : pour y prendre des éléments et les mettre dans le sprint backlog

Page 4 sur 16
 Page 5 sur 16

o Le dernier incrément réalisé : démo du produit et l’avoir en main pour mieux

comprendre ce qui doit être réalisé.
o La capacité projetée par l'équipe de développement pendant le Sprint et les
performances passées de l'équipe de développement  ça se traduit par la
VELOCITE (indicateur utilisé dans les équipes scrum). Mais n’est pas obligatoire.

 La vélocité : c’est la somme des points d’efforts (story points  estimation) des items qui
sont en DONE en fin de sprint. Exemple : si le total des estimations était de X en début de
sprint, la vélocité est de 30 – (nombre de points d’efforts des ITEMS done).

 Vidéo sur comment estimer la charge / l’effort : https://www.youtube.com/watch?

v=Y6UNUcjJjGY

 Les items qui feront partie de la sprint backlog revient uniquement à l’équipe de réalisation
(qui réalisent le produit : développeurs, testeurs …). Le PO n’a pas son mot à dire dans la
capacité de l’équipe de réalisation.

Comment faire pour réaliser le travail d’un sprint :

L’équipe de développement planifie le travail pour transformer cette fonctionnalité en un incrément

produit « Fini » durant le Sprint.

Avant la fin de la sprint planning, l’équipe de développement décompose le travail prévu pour les
premiers jours du Sprint, souvent jusqu'à une granularité d'une journée ou moins. L'équipe de
développement s'autoorganise pour entreprendre le travail consigné au Backlog Sprint, à la fois
lors de la réunion de Planification du Sprint et quand cela est nécessaire tout au long du Sprint ( ?)

Le Product Owner peut aider à clarifier les éléments du Backlog Produit choisis et à faire des
compromis. Si l’équipe de développement détermine qu’elle a trop ou pas assez de travail, elle peut
renégocier les éléments du Backlog Produit choisis (ici on parle donc bien de la sprint backlog) avec
le Product Owner. L’équipe de développement peut également inviter d’autres personnes à la
réunion pour recevoir des conseils techniques ou liés au domaine.

2- Le DAILY SCRUM

Dès que le sprint commence, l’équipe va faire le DAILY SCRUM chaque matin.

 OBJECTIF du daily : C’est une cérémonie pour synchroniser l’équipe de réalisation ensemble.
Cérémonie qui est timeboxée à maximum 15 minutes ou chaque membre explique :
o Ce qu’il a fait le jour d’avant qui permet à l’équipe de dév d’atteindre l’objectif du
sprint
o Ce qu’il fera le jour courant
o s’il y a une alerte à remonter (contraintes, obstacles) qui ne permettent pas de
respecter l’objectif du sprint
C’est aussi s’assurer qu’on va dans la bonne direction de l’objectif du sprint en cour et
s’assurer que le travail à effectuer au quotidien va permettre de réaliser cet objectif.
 A lieu à la même heure et même endroit pour réduite la complexité.
 A lieu même le jour de la sprint planning
D’autres personnes, en dehors de l’équipe de développement, peuvent assister à la daily.
Cependant elles ne doivent pas perturber l’objectif de la daily. Le scrum master peut
intervenir et s’assurer que ces personnes ne vont pas la perturber.

Page 5 sur 16
 Page 6 sur 16

La daily n’étant pas suffisante, les membres de l’équipe peuvent se voir après et discuter plus
en détail.

Voir ces 2 vidéos :

 Comment bien réaliser le daily scrum : https://www.youtube.com/watch?

v=Cf2Z1A5SdpM
 Les 10 erreurs à ne pas commettre en Daily scrum : https://www.youtube.com/watch?
v=IAPE1954MEo

3- La SPRINT REVIEW (Revue de sprint)

Chaque sprint se termine par 2 cérémonies successives :

La 1ere : c’est la SPRINT REVIEW

Vidéo pour plus d’informations : https://www.youtube.com/watch?v=seLIoeSm3l0

10 erreurs à ne pas comment en sprint review : https://www.youtube.com/watch?v=87UOKC9EOUU

 Objectif : ce n’est pas une cérémonie pour faire une démo. C’est une cérémonie ou
l’ensemble de l’équipe scrum et les parties prenantes sont invitées pour faire le point sur ce
qui a été réalisé durant le sprint et voir si l’objectif du sprint a été respecté. Et s’il n’a pas
été respecté pour une raison donnée, essayez de retravailler ensemble et voir comment le
faire respecter sur le prochain sprint.
 C’est une cérémonie pour faire la revue de tout ce qui s’est passé durant ce sprint et voir
l’état d’avancement sur le produit final.
 Il faut également inviter les sponsors, utilisateurs, les parties prenantes à venir voir le produit
afin de récolter un maximum de feed backs.
 Elle est time boxée (au maximum 4h) pour des sprints d’un mois. Moins de temps pour des
sprint plus cours.
 Les participan8ts collaborent sur les prochains travaux qui pourraient être faits pour
optimiser la valeur
 Organisée par le PO (principal) qui invite l’ensemble des participants et le SM (second)
 C’est durant la sprint review ou le PO indique quels sont les éléments qui ont pu passer en
DONE + discute des dates prévisionnelles et date de livraisons prévues ( ?)
 L’équipe de DEV discute des contraintes et problèmes rencontrés durant le sprint et
comment elle à fait pour les surmonter + fait la démo des nouvelles fonctionnalités du
produit
 La revue de sprint fournit une contribution précieuse à la prochaine sprint planning.
 La revue des délais, budget, fonctionnalités potentielles et conditions de marché pour les
prochaines versions prévues de la fonctionnalité du produit.
 Le résultat de la revue de sprint est un Backlog Produit révisé qui définit les éléments
probables pour le prochain Sprint. Le Backlog Produit peut également être globalement
ajusté pour répondre aux nouvelles opportunités d’affaires.

4- La SPRINT RETROSPECTIVE

La 2eme cérémonie pour clôturer le sprint intégralement : la SPRINT RETROSPECTIVE

 La rétro de façon théorique : https://www.youtube.com/watch?v=QT1WhAs75Z8

Page 6 sur 16
 Page 7 sur 16

 La rétro de façon pratique : https://www.youtube.com/watch?v=c2iWd5nnGE4

Objectif et rôle :

 Atelier ludique permettant de travailler sur les problèmes rencontrés et d’y définir 3
améliorations clés à mettre en place dès le prochain sprint  c’est ce qui s’appelle
l’amélioration continue.
 Toute l’équipe scrum (PO, SM, Dév) y participent.
 Permet de discuter de la manière dont le sprint s’est déroulé
 Identifier les améliorations potentielles et créer un plan pour les mettre en œuvre
 Lors de chaque rétrospective de Sprint, l'équipe Scrum propose des moyens adéquats pour
accroître la qualité du produit tout en améliorant les processus de travail
 Revoir/réadapter la définition of DONE (essentiel pour la qualité du produit)

Scrum ne dit pas COMMENT faire ces cérémonies mais donnera plutôt l’OBJECTIF de chacune d’entre
elles.

En résumé concernant toutes les cérémonies scrum consulter ce lien :

https://blog.myagilepartner.fr/index.php/2018/08/17/ceremonies-sprint-scrum/#:~:text=Sprint
%20scrum%20%E2%80%93%20sprint%20planning&text=%E2%80%93%20Les%20animateurs
%20%3A%20c'est,intervenir%20en%20cas%20de%20besoin.

Les 3 rôles clés SCRUM :

 Le scrum master :
o gardien de la méthodologie. Aide l’équipe à gagner en autonomie, à trouver les
bonnes pratiques, à apprendre comment soulever les obstacles.
o Il va coacher les product owner, coacher l’équipe de réalisation
 Vidéos à ce sujet :
1- Informations générales détaillées : https://www.youtube.com/watch?
v=sNYuZkg0tCo

Rôle :

Gardien de la méthodologie : aide l’équipe à bien comprendre la méthodologie

Comment faire les cérémonies et à quoi elles servent
Aide l’équipe de réalisation à prendre son autonomie et à bien appliquer les
cérémonies
N’est pas le maitre de cérémonie de la sprint planning (c’est le product owner)
Formateur de l’équipe à l’agilité et à bien comprendre le scrum
Aide l’équipe à lever les obstacles et amener peu à peu l’équipe à lever elle-
même les obstacles
Ce n’est pas un chef de projet technique ni fonctionnel : c’est à l’équipe
technique (réalisation) de faire la documentation technique et au product owner
de réaliser les documents fonctionnels. Il a un rôle neutre sur le produit.
En daily scrum : aide l’équipe à faire un bon daily scrum, aide l’équipe à ne pas
dépasser un temps de parole de 2 minute, à ne pas dépasser 15 min sur tout le

Page 7 sur 16
 Page 8 sur 16

daily. Il va arbitrer au début, car l’objectif est que l’équipe de réalisation est de le
faire sans sa présence.
Le scrum master doit mettre en place la rétrospective et l’animer intégralement.
Il va faire toute l’animation. Si certains membres de l’équipe veulent réaliser la
rétrospective il peut être amené à les laisser faire.
Donne son avis au PO sur la priorisation des items du backlog, sur la rédaction
des US
Il n’est pas là juste pour animer des cérémonies
Un scrum master « intégré » fait partie de l’équipe dév par exemple est
extrêmement déconseillé

2- Comment devenir un bon scrum master : https://www.youtube.com/watch?

v=paXT0LpZG68

3- Scrum master, emploi bullshit ? : https://www.youtube.com/watch?

v=HLWX50UsafM

 Le product owner : c’est le responsable de la backlog (sac qui rassemble l’ensemble des
demandes pour la réalisation du produit). Il en est responsable : Rédaction des US, les
prioriser, s’assurer que les équipes de réalisation aient toutes les informations
nécessaires pour la réalisation des éléments.
Le product owner peut déléguer ses taches (comme la rédaction des US, ce n’est pas
forcément lui qui les écrits, mais il en reste responsable) mais reste responsable de la
priorisation du backlog dans son ensemble.
A partir du moment où il donne les choses à réaliser à l’équipe de réalisation, il n’a plus
aucune responsabilité à partir de ce moment-là.

 Vidéo à ce sujet : https://www.youtube.com/watch?v=mgNuriDHfGY&t=36s

 Comment devenir un bon product owner : https://www.youtube.com/watch?
v=SwyMISazE2s

Role :

 Il est responsable de la backlog ce qui veut dire :

o Expression claire des items du backlog produit
o Ordonnancement des items dans le backlog pour mieux réaliser les objectifs et les
missions
o Optimisation de la valeur du travail effectué par l’équipe de dév (priorisation)
o Assurance que le BP est visible, transparent et clair pour tous et montre sur quoi
l’équipe de développement travaillera prochainement
o Avoir une de là où il va vision
o L’assurance que l’équipe de dév à bien compris les items du backlog produit
 Responsable de la rédaction et priorisation des users stories
o Users stories permettent de décrire un besoin utilisateur et d’expliquer aux équipes
de développement (et équipes externe) comment répondre à ce besoin.
o Met le client au centre de l’attention : invite les parties prenantes, clients,
utilisateurs, sponsors à différentes review pour donner leurs feedbacks. S’ils ne sont

Page 8 sur 16
 Page 9 sur 16

pas disponibles, organiser des points démo pour être sûre que les prochaines US
répondent bien parfaitement au besoin utilisateur
 Gère la stratégie du produit : doit comprendre la stratégie de l’entreprise par rapport au
produit. Doit gérer le budget à tenir par l’entreprise.
 Le PO doit pouvoir dire NON : doit prioriser dans la meilleure voie possible.
 Doit participer à la rétrospective
 Le PO n’est pas responsable de tester les US en done
 Le PO n’est pas là pour vérifier le travail des équipes de réalisation : il n’est pas responsable
du delivery
 Mettre un business analyste dans l’équipe de développement n’est pas anti-scrum. Il faut
privilégier de dire c’est un membre de la dev team qui à des compétences en BA. Il va par
exemple rédiger les items/US techniques  scrum n’interdit pas de le faire MAIS le
responsable de la priorisation de ces US/ITEMS restera toujours le PO.
 Le PO n’est pas responsable du delivery (du produit), ne teste pas. Il est responsable de la
backlog  c’est la différence entre un PO et un chef de produit/projet. Voir vidéo :
https://www.youtube.com/watch?v=nIdmqKTbSv0
 Pour le PO il devient encore plus difficile d’avoir et de prioriser un backlog de qualité lorsque
la dev team est affecté à plusieurs produits en même temps, même de façon partielle (2
jours par sprint). La dev team doit se consacrer intégralement à un seul produit. Il devient
difficile pour le PO de faire de la prédictibilité.
 When a product grows, it is quite possible that the PO will get help from other Product
Managers and others in the organization who interact regarding the customer facing
activities and knowledge of the product marketplace. While it is fine for the PO to be aided
by the aforementioned people, it is NOT acceptable for the PO to attempt to proxy or
outsource their PO Scrum Team duties, especially the Scrum Team facing duties.


Capsule : Différence entre PO et BA

1. Le PO décrit ce qui doit être réalisé dans le produit  engagé dans le sprint

Page 9 sur 16
 Page 10 sur 16

2. Le BA décrit COMMENT ce sera réalisé (il fait donc partie de l’équipe de réalisation) 
impliqué dans le sprint.

Comment rédiger une User story : https://www.youtube.com/watch?v=nttwWkKED2I

 L’équipe de développement : ce n’est pas juste l’équipe des développeurs. ce sont

toutes les personnes qui participent à la réalisation du produit. Tous ceux qui ne sont pas
scrum master ou Product Owner font partie de l’équipe de développement sauf s’ils
participent à la réalisation du produit. Ils sont 100% responsable du delivery. Elle réalise
le produit, et sont responsable des tests.

Rôle :

 Doivent tester les items en DONE : ils sont 100% responsables du delivery
 Vidéo sur qui est dans l’équipe de réalisation : https://www.youtube.com/watch?
v=QNgTOCvp2Zk
 A la fin du sprint, l’équipe fournit des éléments potentiellement publiable (mis en DONE 
c’est une RELEASE) mais ne sont pas forcément mis en production, ce n’est pas une
obligation. Tout dépend de la stratégie du PO.
 Chaque membre de l’équipe de développement n’est pas pluridisciplinaire mais l’équipe en
soit l’est (on peut avoir des développeurs, architectes, testeurs…)
 En scrum, il n’est pas interdit d’avoir un leader si l’équipe de réalisation est d’accord
 Si besoin d’avoir une compétence d’architecture, elle doit être dans l’équipe de
développement.

Les artefacts :
Il définit 4 artefacts : 3 artefact classiques et 1 artefact de transparence

 Product backlog : (backlog produit)

C’est l’ensemble des demandes qui représente les besoins des utilisateurs. Dynamique.
Reçoit continuellement de nouvelles demandes car il respecte la notion de scope variable pas
comme un cahier des charges. C’est un sac de demandes.
 Vidéo à ce sujet : https://www.youtube.com/watch?v=p1aTlXjNOx0&t=1s

Le PO est le seul responsable de la BP, de son contenu, disponibilité et ordonnancement.

Le BP évolue au fur et à mesure du produit et contexte. Il est dynamique
Le BP contient :
o Les fonctionnalités,
o Les fonctions,
o Les exigences,
o Les améliorations
o Les corrections
Les éléments du backlog produit se composent :
o D’une description
o D’un ordre
o D’une estimation
o d'une valeur.
o Incluent souvent une description du test à effectuer une fois que l’élement sera
« DONE »  pas obligatoire

Page 10 sur 16
 Page 11 sur 16

- Plusieurs équipes scrum travaillent autour d’un même produit.

Product backlog refinement :

Le product backlog doit être raffiné continuellement. Pour cela il faut utiliser le concept du
« product backlog refinment ». Anciennement appelé grooming (terme interdit maintenant).
Le product backlog refinement peut etre réalisé soit :
o Sous forme de cérémonie
o En just-in-time (juste à temps)
Consistes-en :
o L’ajout de détails, d’estimations et de l’ordonnancement (éléments à mettre le plus
haut sur le BP) des éléments du BP ;
o Activité régulière qui se fait entre le PO et équipe de réalisation ;
o Les éléments peuvent toutefois être modifiés à n’importe quel moment par le PO (ou
à sa discrétion) ;
o Action du quand et comment est décidée par l’équipe scrum ;
o N’occupe pas plus de 10% du temps de l’équipe de développement

Les éléments prioritaires sont généralement plus détaillés que ceux qui se trouvent un peu plus loin
dans la BP.

Les éléments sélectionnés dans le sprint backlog sont réputés pour « prêts » (ils ne parlent pas ici de
la « definition of ready »)

L’équipe de développement est responsable de réaliser les estimations

l’ensemble de l’équipe va estimer la backlog, va estimer, va valoriser ses éléments. Et comme la

backlog est dynamique il faut penser à la reprioriser régulièrement.

 vidéo a ce sujet : https://www.youtube.com/watch?v=ahAaGy474F4

Comment suivre la progression vers l’atteinte d’un objectif ?

Le PO peut calculer à tout moment la somme du travail restant à l’équipe au moins à chaque revue
de sprint

Pour calculer la projection : voir méthode, pour faire le suivi des objectifs qu’on se donne.

 Burnup
 burndown,
 cummulative flow

relire cet article sur burdown et burnup: https://www.ecommercemag.fr/Thematique/methodologie-

1247/fiche-outils-10182/burndown-chart-sprint-308284.htm#

relire cet article sur cummulative flow : https://excellenceagile.com/2015/09/23/lecture-dun-

cumulative-flow-diagram/

 Sprint backlog :
Le sprint backlog = éléments péchés depuis le BP + plan pour le livrer durant le sprint
La sprint backlog est dynamique.

Page 11 sur 16
 Page 12 sur 16

Quand les demandes arrivent en sprint planning et qu’on les affecte à l’équipe de réalisation
(qui également participe au choix des US), on prend les demandes du product backlog pour
les mettre dans le sprint backlog.
Il faut intégrer dans le SB les améliorations définies dans le précédent sprint rétrospective.
Si du nouveau travail émerge ou modifications sont nécessaires, l’équipe de développement
peut le rajouter au sprint backlog ou le modifier durant toute la durée du sprint.
Et le sprint backlog est 100% de la responsabilité de l’équipe de réalisation. Il est construit en
début de sprint et détruit en fin de sprint.

Type de représentation du sprint backlog :

L’équipe de développement peut à tout moment calculer la somme du travail restant sur le
sprint afin d’en faire le suivi de progression et en parle durant le Daily.

 Incrément :
C’est le produit en production auquel vient se rajouter toutes les nouveautés considérées
« DONE ». L’incrément augmente à chaque fin de sprint ou on rajoute les nouveaux éléments
d’un sprint au précédent incrément du sprint précédent.
Le PO peut publier l’incrément ou non (reste à sa discrétion)
Doit être dans un état publiable et doit correspondre à la définition of done définie par
l’équipe de développement.
Vidéo à ce sujet : https://www.youtube.com/watch?v=Y-Lali9cz2c

 Le « definition of DONE » (c’est l’artefact de transparence) :

A chaque fois qu’un item doit être passé en DONE, il faut s’assurer que l’ensemble de la liste
des critères est respecté. C’est un artefact de transparence mais également de qualité
Les critères définis permettent de dire qu’un item peut passer en DONE.
Les critères sont définis par l’équipe de développement.
La publication revient au PO en fonction de la stratégie qu’il aura définit (en lot, en livraison
continue…)
Si tous les items ne peuvent pas être réalisés durant un sprint, il ne faut pas que l’équipe de
dév valide l’objectif et doivent revoir avec le PO les items à inclure de telle sorte à atteinte
l’objectif.
Video : https://www.youtube.com/watch?v=aOzJRl9TvLQ

Les termes suivants : velocité, user story, definition of ready… ne font pas partie du framework scrum
mais ont été « inventés » par certaines équipes car jugées utiles dans leurs contextes.

Les 5 valeurs de SCRUM : FORCE

Page 12 sur 16
 Page 13 sur 16

 Focus : une personne qui travaille sur ce produit ne doit travailler QUE sur ce produit. Ne doit
pas travailler 30% sur un produit, 20% sur un autre… Etc
 Ouverture d’esprit :
 Le Respect : on se respecte les uns les autres
 Le Courage
 L’Engagement des équipes

Page 13 sur 16
 Page 14 sur 16

Les 3 piliers scrum :

 La transparence : On est transparent sur l’état d’avancement du produit. Les managers pour
cela utilisent le management visuel : https://www.youtube.com/watch?v=eSrXN7u6Gqw il
ne faut pas mentir sur l’état d’avancement
 L’inspection : l’équipe va s’inspecter elle-même si tout avance dans la bonne direction. Et
donner l’état d’avancement à l’entreprise afin de se réadapter si nécessaire
 L’adaptation : le scrum doit évoluer. On ne va pas faire la mm chose pendant 6 mois.

Il faut bien se rappeler des 3 piliers qui sont très importants.

La stratégie de test AGILE :

Vidéo à ce sujet : https://www.youtube.com/watch?v=abKfFbqi7Uw

Mon backlog : https://www.youtube.com/watch?v=5tMrUkLnkJc

Value driven developement :
https://www.myagilepartner.com/blog/index.php/2019/03/27/value-driven-development-vdd/

Behavior driven developement :

https://blog.myagilepartner.fr/index.php/2017/04/17/bdd-behavior-driven-development/

Product goal :
1. https://www.scrum.org/resources/blog/guide-scrum-2020-comprendre-le-product-goal-en-
7-questions#:~:text=Le%20Product%20Goal%20est%20un,le%20Product%20Backlog%20est
%20affin%C3%A9.
2. https://xavierkoma.com/le-product-goal-en-scrum/
3. https://www.thescrummaster.co.uk/scrum/product-goal-sprint-goals-a-simple-example/?
utm_source=rss&utm_medium=rss&utm_campaign=product-goal-sprint-goals-a-simple-
example

Page 14 sur 16
 Page 15 sur 16

Cone of uncertainty :
https://coach-agile.com/2018/07/incertitude-et-planification-agile/

l’incertitude diminue et la confiance augmente.

Très intéressant : https://agile.toulouse.sqli.com/blog/index.php/2017/08/07/arretez-de-prendre-

decisions-mauvais-moment/

Feature, item, user story, Epic, theme :

https://blog.myagilepartner.fr/index.php/2020/06/09/feature-user-story-epic/
#:~:text=L'Epic&text=En%20fait%20l'Epic%20est,niveau%20sup%C3%A9rieur%20%C3%A0%20la
%20feature.

Story mapping :
https://blog-gestion-de-projet.com/story-mapping/ ET https://blog-gestion-de-projet.com/story-
mapping/

Comment créer une persona :

https://blog.myagilepartner.fr/index.php/2017/07/24/bien-ecrire-son-persona-dans-un-projet-agile/

Definition of Done :
https://blog.thiga.co/glossaire/definition-dod-definition-of-done/#:~:text=La%20Definition%20of
%20Done%20(DOD)%20est%20l'ensemble%20de,la%20qualit%C3%A9%20de%20l'impl
%C3%A9mentation.

Acceptance criteria / critères d’acceptation ou acceptance :

https://blog.thiga.co/glossaire/criteres-dacceptation/ + slide 59

Page 15 sur 16
 Page 16 sur 16

User story INVEST et critères d’acceptation : https://blog-gestion-de-

projet.com/comment-rediger-une-user-story-agile/

Comment prioriser le backlog :

https://www.leproductowner.com/product-owner/comment-prioriser

DOR Definition of Ready : https://blog.thiga.co/glossaire/definition-of-ready-dor/

Calcul ROI : https://blog.myagilepartner.fr/index.php/2017/01/16/prioriser-avec-les-business-
value/#:~:text=Cette%20Business%20Value%20va%20permettre,ROI%20%3D%20Business%20Value
%20%2F%20Complexit%C3%A9.

VELOCITE ET CAPACITE : https://www.nutcache.com/fr/blog/mieux-planifier-avec-la-

velocite/#:~:text=La%20capacit%C3%A9&text=Cet%20indicateur%20repr%C3%A9sente%20la
%20disponibilit%C3%A9,la%20v%C3%A9locit%C3%A9%20moyenne%20sera%20rencontr
%C3%A9e.&text=Une%20%C3%A9quipe%20peut%20aussi%20choisir,PBI%20que%20la%20v
%C3%A9locit%C3%A9%20moyenne.

PRODUCT BACLOG REFINEMENT :

https://blog.myagilepartner.fr/index.php/2017/01/17/la-product-backlog-refinement/

Page 16 sur 16