Quelques notions :

 Pour chacun de ces cycles, on fait une planification adaptée :

o Au niveau du produit, une Roadmap présente ce qui est prévu pour les releases,
c'est du long terme ;

o Un plan de release porte sur le déroulement des sprints, c'est du moyen terme ;

o Un plan de sprint montre les tâches du sprint à réaliser à court terme.

 Product Owner : Représente le client et les utilisateurs. Définit les exigences et priorités
des tâches du backlog et des releases.

Comment calculer la vélocité ?

 Pour la mesurer, il suffit d'additionner le nombre de story points livrés au cours des
derniers sprints et d'en faire la moyenne. Pour avoir une moyenne fiable, il faut calculer
la vélocité sur un minimum de cinq sprints. La vélocité moyenne de cette équipe sera
donc de 35 story points par sprint (35+38+33+36+35÷5=35).

THEORIE SCRUM
Scrum se base sur la théorie du contrôle empirique (empirical process) de processus, ou l’empirisme
(Connaissance provient de l’expérience).
Approche :
- Itérative
- Incrémentale
- Permet d’optimiser la prédictibilité
- Permet de contrôler le risque.
Trois piliers soutiennent l’implémentation d’un contrôle empirique de processus :
 La transparence (transparency) : définition d’un standard commun
 L’inspection (inspection) : Scrum users doivent fréquemment inspecter les artéfacts
Scrum et l’état d’avancement par rapport à un objectif de Sprint (Sprint Goal) et détecter
les ecarts indésirables durant les cérémonies scrum
 L’adaptation (adaptation) : Scrum prescrit quatre occasions formelles d’inspection et
d’adaptation :
Planning meeting or Sprint Planning (Dure au max 4h)  organisé par
 Cérémonie qui débute le sprint.
 Les participants au sprint planning sont le Product Owner, le Scrum
Master et l'équipe de développement.
 Le Product Owner priorise en amont les user stories en fonction de
leur valeur business, mais ce n’est pas lui qui définit la quantité de
travail à embarquer dans l’itération à venir.
 Le sprint backlog se remplie ainsi avec les user stories priorisées par
le product owner, dans la limite de la vélocité de l’équipe.

1
  À la fin du sprint planning l’équipe doit avoir identifié un sprint
goal ainsi qu’un sprint backlog :
o Le sprint goal se résume en 1 ou 2 phrases et représente
l’objectif que s’est fixé l’équipe pour la fin du sprint. Cela
permet de clarifier les attentes vis à vis de l’itération sur le
point de commencer.
o Le sprint backlog est une partie des user stories du backlog
produit que l’équipe s’engage à livrer d’ici la fin du sprint (les
user stories sont mises dans le sprint backlog en fonction de
leur business value et de leur complexité technique). Ainsi, le
travail le plus important s’effectuera en premier.
Objectifs du sprint planning :
o Monter la faisabilité de l’architecture envisagée
o Définir le périmètre du sprint : Définition du backlog
o Décomposition du backlog en User Stories
o Estimation des tâches en heures
o Attribution des tâches

Qui peut annuler un sprint ?

2- Un Sprint peut être annulé avant échéance. Seul le Product Owner a la
capacité d'annuler le Sprint, bien qu'il ou elle puisse se faire influencer dans
cette décision par les parties prenantes, l'Équipe de Développement ou le
Scrum Master. On peut annuler un Sprint si l'objectif visé devient obsolète.

Blacklog Review (1h max) (réunion optionnelle)

o Inclure de nouvelles tâches dans le sprint courant
o On peut se passer de cette réunion s’il y a suffisamment de
tâches à inclure pour le prochain sprint.

Stand up meeting – Daily Scrum (15 min max)

o Evaluer l'avancement du travail de façon objective ;
o Identifier les obstacles nuisant à la progression ;
o Garder l'équipe concentrée sur l'objectif du sprint ;
o 3 questions posées à chaque membre de l'équipe :
 Qu’as-tu fait depuis la dernière fois?
 Que prévois-tu de faire jusqu'à la prochaine
réunion ?
 Qu'est-ce qui pourrait empêcher d'y arriver ?
Technical review sprint (Sprint review dure entre 1 à 2h)
o Montrer ce qui a été réalisé durant le sprint
o Ne montrer que les tâches qui ont étés finies
o Enrichissement du backlog par les bugs découverts
La rétrospective (Sprint Retrospective)
Réunion visant l’amélioration continue du travail et collecter les ressentis des
collaborateurs.

EQUIPE SCRUM (Scrum team)

2
L’équipe scrum comprend :
 Product owner (Propriétaire produit)
 Scrum master
 Devlopement team ( Equipe de développement)
Les Équipes Scrum livrent des produits de manière itérative et incrémentale, maximisant ainsi les
occasions de rétroaction.
Elles sont auto organisée (Self-organizing) et pluridisciplinaires (cross functionnal)
Product owner PO (AMOA, BA)
 Responsable de maximiser la valeur du produit et du travail de l’Équipe de
Développement
 Responsable de la gestion de la back log qui comprend les rôles suivants :
 Exprimer les items de la Back log
 Ordonner les items de la Back log pour mieux réaliser les objectifs et missions
 Optimiser la valeur du travail effectué par l’Équipe de Développement
 S’assurer que le Product Backlog est visible, transparent, et clair pour tous, et
qu’il montre ce sur quoi l’Équipe de Développement travaillera
prochainement
 S’assurer que l’Équipe de Développement comprend adéquatement les items
du Product Backlog.
 La priorité d’un item de la backlog doit être modifiée par le PO seulement. Personne
d’autre n’a le droit de le faire.
 La dev team doit suivre les décisions du PO.
The Development Team
 livrent à chaque Sprint un incrément « terminé » et potentiellement livrable du produit.
 Elle est auto-organisée
 Pluridisciplinaire
 Scrum ne reconnaît pas d’équipes à l’intérieur de l’Équipe de Développement
 Taille de l’Équipe de Développement : doit etre plus de 3 et moins de 9 afin d’avoir
suffisament de ressources pour fournir un travail significatif et ne pas avoir trop de membres
pour mieux gérer leurs coordination. Le PO et SM ne sont pas comptés en tant que membres
de l’equipe
Scrum Master (SM)

ScrumMaster : Sorte de chef de projet coté prestataire. Veille à faire rester la méthode
Scrum au sein de l’equipe projet
Le Scrum Master est responsable de s’assurer que Scrum est compris et mis en œuvre
Ses roles coté PO :
 Trouver des techniques de gestion efficace du Product Backlog
 Aider l’Équipe Scrum à comprendre la nécessité d’avoir des items de Product Backlog clairs et
concis
 Comprendre la planification de produit dans un contexte empirique
 S’assurer que le Product Owner sait comment constituer le Product Backlog pour maximiser
la valeur du produit
 Comprendre et mettre en œuvre l’agilité
 Faciliter les événements Scrum lorsque requis ou demandé

3
Ses roles coté dev team :
 Aider l’Équipe de Développement à développer son auto-organisation et sa pluridisciplinarité
 Aider l’Équipe de Développement à créer des produits de grande valeur
 Éliminer les obstacles au progrès de l’Équipe de Développement
 Faciliter les événements Scrum lorsque demandé ou requis
 Accompagner l’Équipe de Développement dans les environnements organisationnels où
Scrum n’est pas encore entièrement adopté et compris
Lié au sprint planning :
Le Scrum Master veille à ce que le sprint ait lieu et que les participants en comprennent le but. Il
enseigne à l’Équipe Scrum comment respecter la limite de temps associée à cet événement.
Lié à la section Daily :
Le Scrum Master s’assure que la mêlée quotidienne a lieu et apprend à l’equipe de dév comment la
limiter à 15 minutes
Le Scrum Master veille à l’application de la règle stipulant que seuls les membres de l’Équipe de
Développement participent à la mêlée quotidienne.

LES EVENEMENTS SCRUM :

 Créent de la régularité
 Sont limités dans le temps avec une durée maximale
 Chaque évènement est une occasion d’inspecter et d’adapter
 Le sprint contient tous les évènements

Le sprint
 A une durée d’un mois plus ou moins (3 à 4 semaines, maximum 6)
 Objectif est fixe
 Objectif de qualité fixe, ne peut être revu à la baisse
 Chaque sprint est considéré comme un projet avec échéance (3-6 semaines)
 Lorsque l’échéance d’un Sprint est trop éloignée, la définition de ce qui est à développer
peut changer et cela peut accroître la complexité et le risque
Sprint planning
 Dure au max 8h (pour un sprint d’un mois, moins de temps si le sprint est plus court)
 La planification de Sprint répond aux questions suivantes :
1. Qu’est-ce qui peut être terminé au cours de ce Sprint ?
- Choix des items depuis la product backlog par l’équipe des dev et définition du
plan = sprint backlog
- Equipe scrum doit définir l’objectif du sprint à atteinte
2. Comment sera effectué le travail choisi ?
- Une fois le premier sujet traité, L'Équipe de Développement s'auto-organise
pour entreprendre le travail consigné au Sprint Backlog.
- A fin de la planification du Sprint, l’Équipe de Développement devrait être en
mesure d’expliquer au Product Owner et au Scrum Master comment elle entend
s’organiser pour réaliser l’objectif du Sprint et créer l’incrément prévu.
Objectif du sprint
Raison de la construction de l’incrément du produit

4
Toute source de cohésion poussant l’Équipe de Développement à travailler ensemble au lieu
d’entreprendre des initiatives distinctes.
Afin d’atteindre l’objectif du Sprint, l’équipe implémente la fonctionnalité et la technologie
nécessaire. Si le travail se révèle différent de ce qui a été prévu, l’Équipe de Développement
collabore avec le Product Owner et négocie le périmètre du Sprint Backlog durant le sprint.
Annulation d’un sprint :
 Peut être annulé par le PO avant échéance
 En général, un Sprint doit être annulé si son objectif n’a plus de sens compte tenu des
circonstances.
 Quand un Sprint est annulé, tous les items terminés et complétés du Product Backlog sont
passés en revue. Si une partie du travail est potentiellement livrable, le Product Owner
l’accepte. Tous les items non « Terminés » sont estimés à nouveau et réinsérés dans le
Product Backlog.

Le daily scrum
 Réunion quotidienne de Max 15 minutes
 Permet de créer un plan pour les prochaines 24 h
 Trois sujets sont décris durant le Daily :
o Ce sui a été réalisé hier
o Ce qui sera réalisé aujourd’hui
o Les obstacles/alertent empêchant le travail de continuer
 Buts :
o Améliorer la communication
o Prise de décision rapide
o Eliminer les obstacles
o Centraliser les informations et améliorer les connaissances de l’équipe

Sprint review
 Tenue à la fin du Sprint pour inspecter l’incrément réalisé et adapter le Product Backlog si
nécessaire.
 But :
o Le PO fait un rappel des US du sprint terminés ou non
o Présenter le travail terminé par les dév
o Le SM est également présent et veille à faire respecter le but du sprint et boite de
temps
o Discuter des problèmes rencontrés durant le sprint et de comment ils ont été résolus
o Une revue des délais, budget, fonctionnalités potentielles et conditions du marché
pour la prochaine livraison du produit.
Le résultat de la revue de Sprint est un Product Backlog révisé qui définit les items probables pour le
prochain Sprint. Le Product Backlog peut également être complètement revu pour répondre à de
nouvelles occasions d’affaires.

Sprint Retrospective
 Permet à l’équipe SCRUM de s’inspecter et créer un plan d’amélioration pour les prochains
sprints

5
  Survient après la sprint review et avant la sprint planning
 Limitée a 3 h (Pour un sprint d’un mois, sinon moins de temps si sprint moins long)
 Scrum master s’assure que la réunion à bien lieu et fait respecter la boite de temps
(timebox), participe à la réunion.
 Le but de la rétrospective de Sprint est :
o D’inspecter la manière dont le dernier Sprint s'est déroulé en ce qui concerne les
personnes, les relations, les processus et les outils
o D’identifier et ordonner les éléments majeurs qui se sont bien déroulés et les
améliorations potentielles
o De créer un plan pour améliorer les processus de travail de l'Équipe Scrum.

L’équipe Scrum à la fin de la rétrospective devrait avoir identifié les améliorations qu'elle mettra en
œuvre durant le prochain sprint.
Bien que les améliorations peuvent etre mise en place à n’importe quel moment du sprint, la
rétrospective de sprint fournit un évènement dédié et axé sur l'inspection et l'adaptation.

Les artéfacts de Scrum :

 Conçus pour maximiser la transparence d’informations
 Opportunités d’inspection et adaptation

Product Backlog
 Il n’y a qu’un seul back log dans toute la durée de vie d’une produit/projet qui est alimenté par
des évolutions, modifications ou bugs.
 Liste de ce qui recquis dans le produit
 Le PO est responsable du Product back log de son contenu, disponibilité et ordonnancement
 Evolutif et dynamique
 liste toutes les fonctionnalités, besoins, améliorations et correctifs
 Plusieurs équipes scrum peuvent travailler sur la même back log
 les items du Product Backlog (affinage) peuvent être modifiés à n’importe quel moment par
le Product Owner ou à sa discrétion : n’occupent pas plus de 10% de la capacité de l’equipe
de développement
 L’Équipe de Développement est responsable de toutes les estimations. Le Product Owner
peut influencer l’Équipe de Développement en l’aidant dans sa compréhension et le choix
des compromis,
 Le PO peut calculer à tout moment la somme de travail restante et suit son évolution au
moins à chaque revue de sprint. Il compare cette quantité à la somme de travail restant lors
des revues de Sprint précédentes afin d’évaluer le progrès vers l’achèvement du travail prévu
dans les délais voulus par l'objectif.
 Pratiques de projection des tendances :
o Burn down
o Burn ups
o Empirisme (plus utilisée)

Sprint backlog(SB)
 Sprint backlog = Items du product backlog sélectionné pour un sprint + plan de livraison +
objectif
 C’est une prévision des fonctionnalités qui seront livrées dans le prochain incrément
« terminé »
 Rend visible le travail à fournir par les dév

6
  L’Équipe modifie le Sprint Backlog tout au long du Sprint et le Sprint Backlog émerge durant
le Sprint. Cette émergence a lieu alors même que l’Équipe de Développement exécute le plan
et découvre le travail nécessaire pour atteindre le but du Sprint.
 Nouveau travail = ajouter au sprint backlog
 Travail terminé = estimation temps mise à jour
 Items non nécessaires = sont écartés du SB
 L’equipe de dév est la seule à pouvoir changer son sprint backlog : elle appartient
uniquement à l’équipe de dév
 À n’importe quel moment d’un sprint, la somme totale de travail restant dans le Sprint
Backlog peut être calculée. L’Équipe de Développement fait le suivi de cette somme de
travail restant au moins à chaque Daily meeting pour évaluer la probabilité d’atteindre
l’objectif du Sprint. En effectuant le suivi du travail restant tout au long du sprint, l’Équipe de
Développement peut gérer sa progression.

Incrément
 Incrément « done »= items terminés du sprint en cours + incréments des sprints précédents
 L’incrément en fin de sprint doit etre « terminé » et donc utilisable, quel que soit la décision
du PO de le rendre disponible ou non

La transparence des artéfacts

Dans la mesure où la transparence est complète, ces décisions ont une base solide
Le Scrum Master doit travailler avec le Product Owner, l’Équipe de Développement et les autres
parties impliquées afin de déterminer si les artéfacts sont complètement transparents
Le scrum Master peut détecter une absence de transparence en inspectant les artéfacts, en
identifiant certains usages récurrents, en écoutant attentivement ce qui est dit et en détectant des
différences entre les résultats attendus et les résultats réels.

7
Role du product owner

8
Glossaire scrum /traduction (http://www.eveilagile.com/glossaire-agile-scrum/)
Agilité: Capacité d’une organisation à ravir ses clients et ses employés tout en
s’adaptant à temps aux changements de son environnement

Product Backlog / Backlog de produit : Liste des exigences du produit ou plus

exactement liste de tous les éléments sources de valeur qui vont nécessiter
du travail de l’équipe pour réaliser le produit.

Sprint Backlog / Backlog de sprint : Liste des choses à réaliser dans un sprint par
l’équipe de développement.

Backlog Refinement (ou Backlog grooming) : Workshop qui se déroule une à deux fois
par sprint, souvent à mi-sprint, et qui implique tous les acteurs du projet (la
scrum team) (Product Owner, Equipe de Développment, ScrumMaster). Centré
sur le Backlog de produit, le but de ce RDV est de l’affiner et de s’assurer que
les items du Backlog seront prêts à être embarqués dans le prochain sprint.

Task board et burndown chart

scrum task board : Représente les différentes tâches à réaliser ainsi que leur
avancement qui sont modélisés sous la forme d’un tableau. Les tâches sont
représentées par des post-it qui ont tous la même taille, et leur position
indique l’avancement de sa réalisation.
Permet de :
 suivre la progression de la réalisation de chaque tâche d’un sprint
individuellement
Ne permet pas :
 de savoir la quantité de travail restante sur une période donnée.
 De connaitre la quantité de travail à fournir à un instant précis pour la
terminer

Scrum BurnDown Chart (ou scrum chart ) :

 Permet de représenter sous forme graphique l’évolution de la quantité
de travail restante pour une période donnée, pouvant être déduit du
scrum board
 Sur le scrum burndown, on place généralement la quantité de travail
restante en ordonnée (sur l’axe vertical), et le temps sur l’abscisse (sur
l’axe horizontal) :
o L’unité de temps est généralement le jour.
o La quantité de travail étant quant à elle exprimée en jours, en
points ou plus souvent, en nombre de tâches à réaliser.
 Le graphique se lit de gauche à droite, le point de départ étant situé à
l’extrême gauche, sur le jour 0, le point final situé le plus à droite
représentant le dernier jour du sprint.
 Le scrum chart est initialisé en début de sprint
 Chaque jour, lors du daily meeting, le nombre de tâches restant à
réaliser est réactualisé et le graphique évolue ainsi, en plaçant
quotidiennement un nouveau point sur le scrum chart.
 IL est actualisé et tenu par le PRODUCT OWNER and is visible to the Scrum
Team and its stakeholders.

9
  What happens if the Product Owner fails to create and/or maintain the team’s Product
burndown chart? Most likely we will be unable to see if the team is on track, late or
early in its delivery of value

BurnUp Chart : Graphique permettant de visualiser l’avancement du travail
accompli dans une version.

Coach Agile: Métier consistant à accompagner pour une durée déterminée une
organisation, une équipe ou une personne dans son parcours vers ou
dans l’agilité, pour des résultats concrets et mesurables

DOR – Definition of ready (définition du Prêt): Checklist co-construite par l’équipe de

développement et le Product Owner afin de définir la notion de « prêt » d’un
item, c’est à dire sa capacité à être embarqué dans un sprint.

Equipe de Développement : L’un des 3 rôles du cadre de travail SCRUM. L’équipe

de développement réalise le produit.

Kanban : Approche utilisée dans le développement logiciel pour fluidifier le

processus de création de valeur

Lean Software Development: Adaptation au monde IT des principes qui ont fait le
succès de Toyota, dans le secteur automobile, au travers notamment du
Toyota Production System (TPS)

Management Agile : Au départ, fin des années 2000, le management agile

caractérisait une description du rôle des managers travaillant au sein
d’organisations qui se voulaient agiles (notamment dans les DSI). Avec le
temps, le management agile, s’est élargi pour devenir une nouvelle posture
managériale, innovante, accompagnée de nouvelles pratiques qui viennent
dépoussiérer un champ n’ayant guère évolué depuis un siècle.

Mêlée Quotidienne (Daily Meeting) : L’un des 4 événements du cadre de travail

SCRUM. C’est un court point de coordination quotidien (15 minutes maximum)
permettant à l’équipe de développement de se synchroniser et de montrer
l’avancement sur le projet.

Persona: Utilisateur-type, ARCHETYPE, une représentation fictive des

utilisateurs cibles, qu’on peut utiliser pour fixer des priorités et guider nos
décisions de conception d’interface.

Planning Poker : Technique pour estimer l’effort de réalisation des items du

Backlog de produit.

Product Owner : L’un des 3 rôles du cadre de travail SCRUM. Il est le

responsable du produit, le représentant du client et des utilisateurs et donc à
ce titre l’interlocuteur privilégié de l’Equipe. En savoir plus:

Scrum : Méthode agile la plus populaire et la plus utilisée. Inventé en 1996 par
Mike Beedle, Jeff Sutherland et Ken Schwaber, c’est un cadre de travail
(framework) facilitant la réalisation de produit informatique.

10
Scrum Master : L’un des 3 rôles du cadre de travail SCRUM. Animateur d’une
équipe qui applique la méthode Agile Scrum, le ScrumMaster aide l’équipe à
travailler de manière autonome et à s’améliorer constamment. Il est le
garant de Scrum sur le projet. Dans les grandes lignes, le ScrumMaster va
principalement agir en facilitateur, va protéger l’équipe et lever les obstacles
empêchant l’équipe d’avancer.

Scrum Team (Equipe Scrum) : Rassemble les 3 rôles du cadre de travail

SCRUM : Equipe de développement, Product Owner et Scrum Master.

Sprint / Itération : Période de temps de durée fixe, plutôt courte (1 à 4 semaines

– voir un mois calendaire) durant laquelle vont s’enchaîner un certain nombre
d’activités et se terminant par une livraison d’un incrément de produit qui
fonctionne.

Sprint Planning (Planification de Sprint) : L’un des 4 événements du cadre de travail

SCRUM. Il marque le début du sprint et répond aux questions suivantes :

 Qu’est-ce qui peut être terminé au cours de ce Sprint ?

 Comment sera effectué le travail choisi ?

Sprint Review (Revue de Sprint) : L’un des 4 événements du cadre de travail

SCRUM. Il marque la fin du sprint, et se tient pour :

 Inspecter l’incrément réalisé : faire la démonstration de ce qui a été

fait
 Adapter le backlog de produit si nécessaire.

Sprint Rétrospective (Rétrospective de Sprint) : L’un des 4 événements du cadre de

travail SCRUM. L’occasion pour l’Équipe Scrum de :

 s’inspecter
 créer un plan d’amélioration qui sera mis en place au cours du Sprint
suivant.

Story Point : Unité d’estimation attribuée à une user story. Le story point (ou
point d’effort) représente l’effort pour réaliser une user story.

User Story : Exigence du système à développer, formulée en 1 ou 2 phrases et

source de valeur pour un utilisateur.

Vélocité: Mesure du nombre total de points d’EFFORT des User Stories

terminées dans un sprint donné.

Framework : cadre de travail

La RoadMap définit les différents releases prévus dans le cadre d’un projet
Release : est définit par une suite de Sprints : livraison d’un produit/partie d’un produit.

11
12