Unofficial

Scrum Guide

Yannick Quenechdu

Scrum
Ce guide Scrum a pour objectif de vous aider vous souvenir des rgles
proposes par Scrum. Ce guide Scrum doit aussi vous permettre de crer un
environnement de travail agrable et productif auprs de vos quipes.
Pour les dbutants de Scrum, si vous suivez ce guide,
il vous permettra de raliser avec succs vos premiers
Sprints. Ce succs sera facilit par la propagation de
Scrum dans votre entreprise.

Les rgles gnrales des

crmonials
Les bases
Chaque crmonial commence lheure et termine lheure
Chaque crmonial est un crmonial ouvert. Tout le monde peut y assister
Chaque crmonial est une itration

Pour les confirms, utiliser votre bon sens pour ajuster

les processus en vous laissant guider par le guide
Scrum
Pour les Scrum master expriments - utilisez le guide
Scrum pour vous scuriser dans les situations
stressantes.

Le guide Scrum ne fait pas office de formation Scrum

Le guide Scrum ne remplace pas lexprience et la pratique
Le guide Scrum nest pas une procdure que vous devez suivre
Le guide Scrum permet de vous aider mettre en place Scrum dans un
environnement exigeant
Garder en mmoire :

10 bonnes pratiques

1. Avoir une vision claire.

2. Le Backlog de produit doit tre bien maintenu.
3. Le Backlog de produit doit tre tri par la valeur mtier.
4. Les lments du backlog sont estims par lquipe.
5. Le Daily Scrum doit se tenir.
6. Le Burndown de lquipe doit tre mis jour.

Prparation
Inviter en avance toutes les personnes qui sont ncessaires afin quelles aient le temps
de se prparer
Indiquer dans lagenda lobjectif et les attendues du crmonial
Rserver toutes les ressources ncessaires pour le crmonial (salle, rtroprojecteur,
etc.)
Adresser un rappel 24 heures avant le crmonial
Prparer un tableau avec les rgles du crmonial

Faciliter le crmonial
1. Lanimateur doit tre prsent lors du crmonial. Il nest pas autoris participer la
discussion, mais il doit la suivre et ramener la discussion sur le sujet dans le cas o les
participants perdent lobjectif de ce crmonial.
2. Lanimateur prsente lobjectif et lagenda du crmonial.
3. Si ncessaire, lanimateur dcide qui doit prendre les notes durant le crmonial.
4. Lanimateur pourra aider lquipe formaliser les conversations via le tableau pour
visualiser les changes.
5. Lanimateur sassure de la concentration de lquipe avec des outils comme le Parking
lots pour saisir les demandes ou les questions qui nont pas de liens directs avec le
crmonial, de manire quelles puissent tre abordes plus tard.
6. Lanimateur donne un travail d'intrt gnral aux retardataires

7. Le Sprint nest pas perturb par le client ou la direction.

8. Le logiciel fourni par lquipe de ralisation est termin.
9. La revue de Sprint doit tre collaborative.
10. La rtrospective doit mettre la priorit sur lamlioration du processus de
travail de lquipe et de lorganisation.

En sortie :
Prise de note. Prenez des photos du contenu du tableau
Compte rendu du crmonial qui est saisi dans un outil collaboratif

Diviser votre organisation en petites quipes pluridisciplinaires

Diviser le travail en petits livrables oprationnels

Diviser le temps en petites itrations fixes

Scrum
Pratiques

Les Scrumers
Scrum Master
Le Scrum master protge lquipe de toutes les
perturbations extrieures.
Il peut faire partie de
lquipe. Cest un leader et un animateur. Il maintient
la productivit de lquipe Scrum et ralise les
contrles sur le cycle de vie vrification et
adaptation. Il protge lquipe et travaille avec le
Product Owner pour maximiser le ROI. Il sassure que
lagilit est respecte par lensemble des quipes. Il
est en charge des obstacles remonts par lquipe.

Client
Le client est le demandeur du produit auprs de lquipe
Scrum. Il contractualise le dveloppement du produit. Il
est frquent que les dveloppements soient confis un
prestataire. Dans le cas o le dveloppement est ralis
en interne, cette personne peut tre le responsable du
budget pour le projet.

quipe

Product Owner

Lquipe dlivre le produit et elle est responsable de

sa qualit. Lquipe travaille avec lensemble des
demandeurs - le client et les utilisateurs pour crer le
Backlog de produit. Lquipe analyse le Backlog de
produit afin que ses membres aient toutes les
informations
pour
dvelopper.
Lquipe
est
responsable de la conception et fournit les
fonctionnalits prvues. Lquipe est responsable de
son travail. Lquipe travail continuellement avec le
Product Owner pour dfinir lorientation stratgique
du projet de dveloppement du produit.

Le Product Owner dirige le projet dun point de vue du

mtier. Il communique une vision claire du produit et en
dfinit les caractristiques principales. Il accepte ou
rejette le produit la fin dun sprint. La responsabilit
principale du Product Owner est de veiller ce que
lquipe travaille seulement sur la partie la plus
importante du Backlog. Il a le mme objectif que
lquipe et laide raliser son travail durant un sprint,
en vitant dtre perturbe par dautres membres et en
donnant rapidement les informations dont lquipe a
besoin. Le Product Owner est responsable du ROI.

Lutilisateur
Manager
Le management est une partie essentielle dans
lorganisation de Scrum. Le management permet aux
quipes de travailler dans un bon environnement. Le
manager cre la structure et apporte la stabilit. Il
travaille aussi avec le Scrum Master pour faciliter le
travail des quipes au sein de lorganisation.

Le rle de lutilisateur peut tre endoss par un certain

nombre dacteurs de lentreprise. Ce peut tre par
exemple, un sponsor du projet ou une personne du
dpartement marketing. Le vritable utilisateur est un
expert dans le domaine adress par le produit ou un
consultant que vous avez engag pour ses
connaissances fonctionnelles. Lutilisateur est pour tous
la source d'informations privilgies pour dcider de la
priorit et des dtails des fonctionnalits.

Artefacts

Burndown charts

Les quipes utilisent des Artefacts pour les accompagner sur leurs
projets Scrum. Ce sont des outils pour suivre et amliorer lefficience de
lquipe durant un projet. Ils sont bass sur les bonnes pratiques du
management visuel.

Ce graphique reprsente la quantit totale de travail faire dans le

sprint, au fil des jours. Il permet d'avoir une vue sur l'avancement du
sprint

Backlog de produit - La liste des fonctionnalits

Le Backlog de produit est une liste qui contient des ides,
exigences, fonctionnalits, user Stories, etc. Cest la liste
des lments que lon veut raliser dans son projet.
Lensemble des lments du backlog de produit sont
tries sur une base mtier et sur la valeur ajoute pour
lapplication

Backlog de sprint - le contenu du sprint

Le Backlog de Sprint est une liste dlment provenant du
Backlog de produit. Cette liste contient les lments que
le Product Owner souhaite faire dvelopper durant le
sprint.

Impediment Backlog - La liste des blocages

Le Scrum Master utilise cette liste pour visualiser les
blocages qui impact sur la productivit de lquipe. Elle
reflte aussi les lments qui doivent tre dbloqus le
plus rapidement possible.

Le graphique de Burndown affiche chaque jour le reste faire

des Story Point

Laxe vertical affiche les Story Point, laxe horizontal affiche les
jours du sprint en cours

Lquipe met jour le graphique de Burndown lors du Daily

Meeting

Un graphique de Burndown doit tre facile mettre jour par

lquipe. vitez-le fantaisiste ou difficile maintenir.

Produit potentiellement utilisable - Le rsultat

la fin dun sprint, lquipe
potentiellement utilisable.

dlivre

un

produit

Sprint planning 1re partie

Lobjectif de ce crmonial est de prsenter en dtail ce que le
Product Owner souhaite faire construire durant le sprint. Il permettra
lquipe de dveloppement davoir une image claire de ce qui est
attendu durant ce sprint. la fin du crmonial, lquipe sera en
mesure de dire ce quelle peut accomplir durant les prochaines
semaines.

Base :
Seuls les membres de lquipe dcident des Users Stories qui
pourront tre ralises durant ce sprint

Ingrdients :

O
Place au P
Les Users Stories pour le

Procdure :
1. Le Product owner prsente le but de ce sprint et les Users Stories qui le
composent.
2. Lquipe tudie avec le Product Owner les Users Stories en discutant des
critres dacceptation et des lments complmentaires tels que la
cinmatique, design, tests, etc.
3. Le Product Owner les clarifie si ncessaire.
4. Lquipe doit avoir une vision de toutes les Users Stories qui pourront
passer dans le sprint.
5. Lquipe choisit les Users Stories qui pourront tre dveloppes dans le
sprint. La vlocit de lquipe doit tre prise en compte.
6. Lquipe commence ses estimations avec la Magic estimation.
7. Elle choisit les Stories points autoriss dans un sprint. Ex : 1,3,5,8
8. Elle positionne sur un tableau des colonnes pour chaque Story Point.
9. Lquipe pose les Users Stories dans les colonnes correspondant leur
estimation.

prochain sprint avec les priorits

en relation avec la valeur mtier

10. Les Users Stories pour lesquelles il ny a pas de consensus sur les
estimations sont sorties du tableau.

Tableau blanc, marqueurs,

11. Lquipe organise un planning Poker pour estimer en Stories Point les
Users Stories restantes.

Planning des congs, fiche

12. Dans le cas o certaines Users Stories sont trop grandes, elles doivent
tre estimes avec de grands chiffres (40, 100) pour indiquer au Product
Onwer quil doit les dcomposer et quelles ne pourront pas tre acceptes
dans le backlog de sprint.

post-its, crayons, etc.

contact des personnes

importantes

Jeux de planning poker et Magic

Estimation

Dure

90 min pour deux semaines de

sprint.
Raliser ce crmonial de
prfrence le matin

13.Le Product Owner devra remanier le Backlog de produit pour prendre en

compte les retours de lquipe effectus durant ce sprint.

En sortie :
Un backlog de sprint estim
Des Users Stories INVEST* qui seront dveloppes dans le cadre de ce
sprint

Ne pas faire :
1. Le Product Owner nestime pas
2. Ne pas dcouper et estimer les tches
* lacronyme INVEST est expliqu en fin de document

Sprint planning 2me partie

Le but de ce crmonial: La conception. Lobjectif du Sprint Planning est
de savoir comment implmenter et de trouver des solutions pour
raliser les Users Stories. la fin de ce crmonial, lquipe doit savoir
comment dvelopper les Users Stories qui seront ralises durant le
sprint. Ce crmonial est ralis la suite de la premire partie du
sprint planning. La prsence du Product Owner nest plus ncessaire.

rend la
p
e
ip
u
q

L
suite..

Ingrdients :

Les

personnes qui veulent aider

lquipe dans la ralisation du
produit durant le sprint

Procdure :
1. Prendre le Backlog de sprint
2. Faites confirmer par lquipe quelle comprend bien le contenu du
Backlog de sprint
3. Lancer la session de conception avec des questions telles que :

Quelles interfaces devons-nous dvelopper ?

Quelle architecture avons-nous besoin de construire ?
Quelles tables devons-nous mettre jour ?
Quels composants devons-nous mettre jour ou crire ?
Quand lquipe a une comprhension claire de la faon dont elle va
dvelopper cette User Story, elle peut prendre la User Story suivante.
Tout au long de ce crmonial, les membres de lquipe utilisent les
post-its pour crire les tches de bases. Cela permet de savoir par o
commencer le lendemain.

Backlog de sprint estim et

INVEST

Tableau blanc, marqueurs,

post-its, crayons, etc.

Les tches associes aux Users Stories sont positionnes sur le tableau
des tches. Il ne faut pas estimer les tches.

Base :
Seuls les membres de lquipe de ralisation conoivent la solution. Les
architectes et les autres personnes hors de lquipe de dveloppement
sont seulement invits aider lquipe de dveloppement. Lquipe
dcide des personnes ncessaires durant ce crmonial

Dure

60 min par semaine de sprint.

Raliser ce crmonial directement aprs le
sprint planning 1re partie

Ne pas faire :
1. Ne pas estimer les tches
2. Ne pas assigner les tches

En sortie :
Un tableau des taches avec lactivit raliser
Des Users Stories INVEST* qui seront dveloppes dans le cadre de ce
sprint

* lacronyme INVEST est expliqu en fin de document

Le tableau des tches

Cest une reprsentation visuelle qui combine des lments
provenant du produit backlog et du sprint backlog

Il est maintenu seulement par

lquipe

3. Test, quand un membre de

lquipe a termin son
dveloppement, il ladresse
lquipe de testeurs qui ralise
les tests

Il est ncessaire davoir un grand

tableau, avec un processus simple. Ce

tableau aide la communication dans
lquipe et analyser rapidement les
problmes dans le projet

Le tableau a au minimum 4
colonnes
1.Users Stories. Les lments
provenant du Backlog de
produit (les Users Stories).
Elles doivent tre positionnes
par ordre de priorits

4. Termin. Quand le
dveloppement est termin
et test, la User Story est
considre comme
termine.

Dfinition de Termin
2. En cours. Quand un membre
de lquipe commence un
dveloppement, il passe le
post-it dans la colonne en
cours

Si une Story ne peut tre

termine, parce quil y a un
blocage, il est ncessaire de la
transfrer dans le tableau des
obstacles,

Clarifier ce que termin veut dire avec votre quipe. Vous

pouvez par exemple organiser avec votre quipe une session de
brainstorming. Durant cette session, il est intressant de crer une
liste qui dcrit en dtail ce que signifie Termin pour votre
quipe.
Des ides :
Le build a t ralis avec succs
Les tests unitaires ont t raliss avec succs
Les tests fonctionnels ont t raliss avec succs
Le code est correctement document

Daily Scrum

Procdure :
1. Lquipe se runit autour du tableau des tches

Le but de ce crmonial est de planifier et de coordonner les activits de

lquipe pour la journe et didentifier les obstacles dans le projet. Le
tableau des tches doit aider lquipe se concentrer sur les activits de la
journe. Profiter du Daily Scrum pour mettre jour le tableau des tches et
le Burndown

2. La personne sur le ct gauche commence expliquer ses

coquipiers ce qu'il a termin hier.
3. Maintenant, cette personne dplace la user Stories/tches sur le
tableau des tches dans la colonne correspondant au nouvel tat.
4.La personne prend une nouvelle tche et la passe dans En cours

Ingrdients :
Tableau des tches
Marqueurs, post-its, crayons,
etc.

Ide:
ster : ne
a
M
m
u
r
c
Pour le s
ant ou
v
e
d
e
r
t
t
e
pas se m
t ches.
s
e
d
u
a
e
l
b
ct du ta
rer une
c
s
a
p
e
n
Pour
e et de
v

d
e
r

atmosph
r.
professeu

Base :

Lensemble de lquipe doit tre prsent

Un membre de lquipe qui ne peut pas tre prsent doit tre
reprsent par un collgue

Dure

le cercle est une bonne forme

15 min, mme temps, mme lieu chaque jour

5. Si cette personne rencontre des problmes ou des blocages, il

lindique au Scrum Master. Ce dernier ajoute un signal sur la tche
pour indiquer le blocage et ajoute une rfrence dans la liste des
obstacles.
6.On recommence les 5 tapes pour chaque membre de lquipe.

Ne pas faire :
1. viter que ce soit le Scrum Master qui soit oblig
de poser les questions (aider lquipe tre
proactive).
2. Ne pas reporter au Scrum Master, mais lquipe.
3. Ne pas faire dvier le crmonial.
4. Ne pas arriver en retard/
5. Ne pas dpasser le temps allou au crmonial.
6. Le Daily nest le moment pour rentrer dans le
dtail des problmes.
7. Le Scrum Master ne doit pas dplacer les taches
pour les membres de lquipe.
8. Le Scrum Master ne doit pas mettre jour le
graphique de burndown pour les membres de
lquipe.
9. Ne pas arriver sans prparation.

Sortie :
Une vision claire de qui fait quoi
Les lments de lImpediment backlog
Les lments pour le Backlog de lquipe

Revue de sprint
Lquipe de ralisation montre le rsultat de son travail lquipe
client et au Product Owner. Elle peut aussi inviter toutes les personnes
qui sont intresses pour dcouvrir ce qui a t ralis durant le
dernier sprint. Lquipe de ralisation souhaite avec un retour du
Product Owner.

Procdure :
1. Le Scrum Master accueille les participants la revue de sprint.
2. Le Scrum Master rappelle aux participants prsents dans la salle
lobjectif initial de ce sprint : Le but du sprint, les Users Stories
proposes par le Product Owner en dbut de ce sprint.
3. Lquipe de ralisation ralise une dmonstration des nouvelles
fonctionnalits sous la forme de scnario de bout en bout.
4. Elle laisse par la suite le Product Owner et son quipe utiliser ces
nouvelles fonctionnalits.
Le Scrum Master est le facilitateur de ce crmonial.

Ingrdients :
Produit potentiellement

utilisable rsultant du dernier

sprint
Tableau, marqueurs, post-its,
crayons, etc.

Base :

La revue de sprint permet tous les participants dutiliser les

nouvelles fonctionnalits prsentes par lquipe de ralisation

Dure

90 min la fin du sprint

Le Product Owner prendre des notes concernant le retour de lquipe

sur ce sprint, pour proposer des ventuelles volutions lors des
prochains sprints

Ide:
de travail
n
io
s
s
e
s
Cest une
pour
t
n
e
m
o
m
e
i l
Cest auss
lles ides
e
v
u
o
n
e
d
rflchir

En sortie :
Le retour de lquipe du Product Owner
La liste des blocages
La liste des Users Stories termines
Ne pas faire :
Ne pas prsenter un produit qui nest pas
potentiellement utilisable
Le Scrum Master ne fait pas la prsentation
Lquipe ne restreint pas la prsentation au seul
Product Owner
Les participants ne ralisent pas de feedback
durant la revue

Rtrospective
Principe

Procdure :

Lobjectif de la rtrospective est de proposer des amliorations

du processus, de lorganisation, des comptences sur le projet
en cours

1. Prparer une colonne Ce qui sest bien pass.

2. Prparer une colonne Ce que nous pouvons amliorer.
3. Prparer une colonne Backlog de rtrospective.
4. Distribuer des post-its chaque membre de lquipe.

Ingrdients :

5. Collecter les faits :

6. Lancer un chronomtre pour une dure de 5 min.
Tableau blanc avec les
marqueurs des post-its

7. Chaque membre de lquipe indique les faits marquants (3 max.) pour la

premire colonne Ce qui sest pass.
8. Chaque membre pose ses post-its dans la colonne Ce qui sest pass.

Seules les personnes prsentes ici

sont obligatoires, les autres
peuvent tre invits

Dure

90 min, 10 minutes
aprs la revue

Base :

9. la fin du chronomtre, il faut recommencer pour la deuxime colonne

Ce que nous pouvons amliorer.
10. Chaque membre pose ses post-its dans la colonne Ce que nous
pouvons amliorer.
11. Une fois lensemble des post its dpos, les regrouper par thme.
12. Une personne de lquipe commence la lecture et chacun peut rebondir
sur le contenu.
13. Les retours, solutions, propositions sont dposs dans le backlog de
rtrospective.

Apprendre du pass pour prparer lavenir

Amliorer la productivit de lquipe

La suite :
Proposer chaque dbut de rtrospective les actions que nous avons pu
amliorer suite la dernire rtrospective
Ne pas faire :
Ne pas juger les avis des autres
Ne pas discuter de lavis des autres hors du
crmonial
Plan daction SMART*

* lacronyme SMART est expliqu en fin de document

Glossaire
Nous prsentons deux acronymes trs couramment utiliss dans les mthodes Agile. INVEST qui permet de dfinir le cadre dune bonne
histoire et SMART pour dfinir correctement une tche.

INVEST

SMART

Indpendant

Spcifique

Les histoires sont plus faciles travailler si elles sont indpendantes les
unes des autres.

Une tche doit tre suffisamment prcise pour que chacun

puisse la comprendre

viter les dpendances entre les Users Stories

Laction est prcise, propre la situation

Penser : Qui, quoi, comment, ou et pourquoi

Dans le cas contraire, il peut y avoir une difficult estimer et appliquer
des priorits
Mesurable
Ngociable
La principale mesure est Peut on la marquer comme
ralise ?
Une bonne histoire est ngociable. Elle capture lessence et non pas le
dtail
Fixer des indicateurs qui nous permettent
Une Story nest pas un contrat
Laisser une flexibilit sur les UserSstory pour que chacun puisse
donner son avis
Au fil du temps, l'histoire volue.
Valeur

d'une part de nous assurer que nous sommes sur la

bonne voie
d'autre part que nous aurons atteint notre objectif avec
cette action
Atteignable

Une User Story a besoin dtre utile

Le propritaire de la tche doit tre en mesure de la raliser

Il faut dfinir la valeur de la user story pour le client. Elle est rdige
pour montrer le bnfice pour lutilisateur

Il est important qu'une quipe puisse cocher objectifs

raliss, afin de mesurer et de vrifier le niveau
daccomplissement.

Il faut adresser en priorit les Users Story qui ont une valeur pour
l'application
Estimable
Une bonne User Story peut tre estime
Parce quune User Story est utilise dans le planning
Small (taille)

Raliste/Pertinents
Elle peut tre ralise dans le cadre dun sprint
Leffort est prvue dans le cadre du sprint
T : Limit dans le temps
Fixer un temps raliste une tche

Les bonnes histoires ont tendance tre petites

Pas daction long terme

Proposer une taille acceptable pour une User Story

Dtermin un temps implique une action spcifique

Une User Story doit tre dveloppe en une semaine maximum

On fixe une date de dbut et dune de fin

Testable
Une User Story doit tre fournie avec les conditions qui permettent de
vrifier quelle correspond aux attentes des utilisateurs.