Scrum RSK

La méthode Agile
SCRUM
Dr. Rim Samia Kaabi

Certifications Agile (unscaled)
Certifications Agile (unscaled)
Sommaire
1. Introduction
2. Méthodes traditionnelles ou méthodes agiles ?
3. Les responsabilités SCRUM
4. Les artéfacts SCRUM
5. Les évènements SCRUM
6. Scrum of Scrums
7. Préparation à la certification
4
Sommaire
1. Introduction
6. Scrum of Scrums
5
Le développement logiciel ?
La Crise du logiciel
• Le génie logiciel :
– Né en Europe à Garmish-Partenkirchen (Allemagne)
– Conférence en 1968 sous le patronage de l’OTAN
– 45 ans déjà, seulement !
• Pour répondre à un certain nombre de problèmes

dans le développement de logiciels
• Les causes 100
80 Matériel
% des 60
– Machines puissantes à coûts modérés

coûts Développement
40
20
Maintenance
0
– Demande et Complexité croissante

1955 1970 1985
Symptômes de la crise du logiciel
• Inadéquation
Produits ou services réalisés ≠ besoins utilisateurs
• Délais
Produits souvent livrés en retard
• Coûts
Dépassement du budget prévu
• Fiabilité
Produits souvent en panne
• Maintenance
Complexe et coûteuse
Les statistiques sont effrayantes
%
100
90
80
70
60 90%
50
40
66%
Livrés
54%
en
retard
N’étaient
30 Livrés
pashors
20 30%
budget
considérés
comme
10 Abandonnés
réussis
avant la fin
0
Source: THE STANDISH GROUP 2003
Cycle de vie du logiciel (CVL)
Avant-projet Exploitation & Retrait
Développement Maintenance
de projet
Gestion
Initiation Planification, Pilotage & Suivi

du projet Gestion de qualité Évaluation
Analyse
Conception
Activités techniques
Implémentation
Tests Maintenance
Étude
&
préalable
Installation Assistance
Documentation
Vérification et Validation (V&V)
Gestion de configuration
Les Outils de gestion mis en œuvre
Program Evaluation
and Review Technique (1958)
1910’s
Sommaire
1. Introduction
3. Les rôles SCRUM
5. Les réunions SCRUM
6. Scrum of Scrums
12
Premiers constats
 Maitriser les 4 variables d'ajustement sur un projet
– Périmètre fonctionnel (ce qu’on veut faire ?)
– Coût (avec quel budget ?)
– Durée (en combien de temps ?)
– Qualité
 Définir et réserver les moyens nécessaires

 Prévoir l’organisation et la gestion du projet
 Fonder la gestion sur des prévisions !!!???
Premiers constats
Limites des approches classiques
• La rigidité du formalisme (la non-prévisibilité de tous les
événements)
• La levée tardive des facteurs à risques (interfaces IHM,
tests de performances, …)
• Les meilleures idées ne viennent pas forcément au début
du projet
– Il est plus facile de construire par étape que tout
imaginer dès le début
• Les besoins peuvent évoluer pendant le projet
• Chiffrages et reste à faire sont difficiles à évaluer
Cône d’incertitude
A la définition du projet, l’incertitude est de 60% et il faut attendre le
design détaillé pour réduire cette incertitude à 10%. Ce qui explique donc
que plus de 2/3 des projets dépassent le coût estimé initialement.
Effets non désirés en management
« Effet Tunnel »
• Définition : Expression imagée
signifiant que l’équipe projet MOA
reste sans nouvelle pendant tout le
temps entre la validation des besoins
et la livraison du module quasi fini…
• Le risque : une dérive multiple – délai,
budget et surtout non-conformité du
produit livré avec la conception
initiale… Ce qui guette toute équipe de
développeurs laissée à elle-même !
Effets non désirés en management
Effet « Perte en ligne »
Réalité des projets informatiques
• Les choses s’améliorent ???
Les raisons d’échec d’un projet
Limites des méthodes traditionnelles
• Les méthodes prédictives, traditionnelles, fonctionnent
bien, à condition d’avoir:
– Stabilité et prévisibilité
– Communication et compréhension parfaite
– Choix parfaits dès le départ
• Une alternative : les méthodes AGILES!!!

Définition de la business Agility
Business agility refers to the "ability of a business system to rapidly
respond to change by adapting its initial stable configuration". It can
be sustained by maintaining and adapting goods and services in
meeting customer demands, adjusting to the changes in a business
environment, and taking advantage of available human resources.
In a business context, agility is the ability of an organization to rapidly

adapt to market and environmental changes in productive and cost-
effective ways. An extension of this concept is the agile enterprise which
refers to an organization that uses key principles of complex adaptive
systems and complexity science in achieving success. Business agility
is the outcome of organizational intelligence.
Agile organizations prefer an iterative and incremental delivery

Qu’est ce qu’une méthode agile?
• Une méthode agile :
– est une approche itérative et
incrémentale,
– est menée dans un esprit
collaboratif, avec juste ce qu’il
faut de formalisme.
– à chaque itération, doit livrer un
incrément de logiciel TERMINÉ
!!
– génère un produit de haute
qualité tout en prenant en
compte l’évolution des besoins
des clients
Pourquoi Agile
Quand utiliser quoi?
Eléments clés de l’agilité
• Rapidité
• Adaptation
• Flexibilité
• Dynamique
• Travail collaboratif
• Confiance
• Auto-organisation
• Pluridisciplinarité
Avantages de l’agilité
Quelques chiffres
84% le travail est plus facile et

plus flexible
75% augmentation de la
productivité
77% plusss de transparence
72% amelioration de la
motivation des équips
71% Faster Market solutions

La pyramide agile : du mindset
aux pratiques !
Comparaison des méthodes
Désinformation sur l’agilité
Adoption de l’agilité
Le manifeste Agile (2001)
On découvre de meilleures façons de développer des logiciels en
le faisant et en aidant les autres à le faire
Les 12 principes du manifeste agile
Les 4 valeurs sont déclinées en 12 principes généraux
Considérer comme
Livrer fréquemment Fonctionnels et
naturel les
Satisfaire le client une application développeurs
changements
fonctionnelle travaillent ensemble
d’exigences
Un logiciel
L’échange Le rythme de
Bâtir le projet fonctionnel est la
d’information le développement doit
autour de meilleure façon de
plus efficace est en être soutenable
personnes motivées mesurer
face à face indéfiniment
l’avancement
Simplicité - l'art de Architectures,

Vérifier en continue Régulièrement,
maximiser la spécifications et
l’excellence des réflexion de l’équipe
quantité de travail à conceptions issues
pratiques et pour être plus
ne pas faire - est d'équipes auto-
techniques efficace !
essentielle organisées
Qu’est ce qu’une méthode agile?
AGILE -> PRATIQUES -> FRAMEWORKS
(SCRUM, XP, KANBAN, SAFE, ETC.)
AGILE FRAMEWORKS
Synthèse des différences fondamentales
entre approche traditionnelle et approche agile
Synthèse des différences fondamentales
entre approche traditionnelle et approche agile
Caractéristiques des méthodes agiles
2 caractéristiques fondamentales:
– Adaptatives plutôt que prédictives

• Être favorable aux changements
• Suivre un formalisme léger  Planification plus souple
– Orientées vers des personnes plutôt que vers les processus

• Adopter un esprit collaboratif
• Travailler avec les spécificités de chacun
Agilité & SCRUM
• Un spécialiste des processus parlerait, pour Scrum, de pattern de

processus, orienté gestion de projet, qui peut incorporer différentes
méthodes ou pratiques d’ingénierie.
Scrum est un cadre agile pour la gestion de projets.
La méthode SCRUM
• Le terme Scrum est emprunté au rugby
et signifie mêlée.
 une équipe soudée, qui cherche à
atteindre un but.
• Scrum a été conçu pour améliorer grandement la

productivité dans les équipes auparavant paralysées par
des méthodologies classiques - plus lourdes.
Scrum: Définition
SCRUM : Tout un jargon
Terme Définition
Scrum Scrum c'est la « méthode » mais c'est aussi le nom usuel de la réunion
quotidienne limitée à un quart d'heure. En anglais Scrum daily meeting.
Sprint Bloc de temps aboutissant à créer un incrément du produit potentiellement
livrable. C'est le terme utilisé dans Scrum pour itération. Dans la pratique, un sprint
dure de 2 à 4 semaines.
Release Une release correspond à la livraison d'une version totalement opérationnelle. Elle
passe par une série de sprints successifs.
Backlog Liste ordonnée de toutes les choses à faire. On distingue :
- le backlog de produit qui énumère les exigences avec le point de vue du client
- le backlog de sprint qui contient les tâches de l'équipe.
User Une User story est une exigence du système à développer, formulée en une ou
story deux phrases dans le langage de l’utilisateur.
Scrum Animateur, facilitateur d'une équipe Scrum. Littéralement le maître de Scrum.

Master
Product Le représentant des clients. Littéralement le propriétaire du produit ou le directeur
Owner du produit.
• Scrum is defined completely in the
Scrum Guide by Ken Schwaber and Jeff
Sutherland, the originators of Scrum.
• The Scrum Guide is maintained
independently of any company or
vendor and therefore lives on a brand
neutral site.
• Read the Scrum Guide!

www.Scrum.org To understand Scrum
and be successful in the exam, it is
essential!
Waterfall versus Scrum
Waterfall versus Scrum
Le cycle Scrum
Composants de SCRUM
ACCOUNTABILITIES
Product Owner (PO)
Development Team (DT)
Scrum Master (SM)
EVENTS
Sprint
Sprint Planning Meeting
Daily Scrum
Sprint Review
Sprint Retrospective
ARTIFACTS
Product Backlog
Sprint Backlog
Increment
DONE
Attention
• Scrum n’est pas une méthode mais un framwork
• Chaque sprint a pour objectif de réaliser un incrément

respectant la DoD (Definition of Done)
Scrum: Pilliers
Pilliers de SCRUM
Pilliers de SCRUM
Pilliers de SCRUM
Valeurs de Scrum
Sommaire
1. Introduction
6. Scrum of Scrums
57
Le Product Owner - PO
Les responsabilités du P.O.
1. Fournir une vision partagée du produit :

• Le P.O. est responsable de définir l’objectif du produit et de le
partager avec l’équipe qui le développe.
• Sa vision consiste typiquement à définir :
– l’énoncé du problème que le produit veut résoudre,
– une position du produit qui soit claire pour tout le monde,
– une liste des fonctionnalités essentielles.
2. Définir le contenu du produit :
• Le P. O. définit le contenu du produit
– identifier les fonctionnalités requises + les collecter dans une liste, appelée
le backlog de produit.
• Le P.O. est responsable du backlog et y contribue de façon régulière.
• Comme il est moteur pour établir ce que doit faire le produit, il est
logique qu’il fournisse aussi ses conditions de satisfaction, qui
permettront de s’assurer que ce qu’il demande est bien réalisé
 il est donc impliqué dans les tests d’acceptation.
• En plus de son travail pour le sprint courant, il s’occupe aussi des

éléments du backlog prévus pour les sprints suivants.
3. Planifier la vie du produit :
• Le P. O. définit l’ordre dans lequel les parties du produit seront
développées.
 Il doit alimenter l’équipe avec les fonctionnalités à développer,
selon ses priorités définies en fonction de la valeur qu’elles apportent.
• L’ordre de réalisation définit le cycle de vie du produit. Cette vie est

constituée d’une succession de versions (les releases).
• Le P.O. définit l’objectif d’une release et prend les décisions sur le

contenu et la date de mise à disposition du produit.
Les compétences d’un P.O.
La personne idéale pour être PO devrait posséder les
compétences suivantes :
• Quelqu'un qui a été Analyste Métier (Business Analyst)

est un bon candidat pour ce rôle.
Choisir le P.O. d’une équipe
• On peut se baser sur les compétences souhaitées du
Product Owner déjà présentées.
• En effet, cette personne doit être :

– Une personne disponible :
• disponibilité continue,
• participation aux différentes cérémonies Scrum,
• implication régulière : MAJ le backlog, ajuster les priorités,
répondre aux questions, définir et aider aux tests d’acceptation
– Une personne motivée pour ce rôle
Quelques conseils pour les P.O.
• Se former
• Collaborer avec l’équipe
• S’impliquer dans les tests d’acceptation
• Utiliser le produit
• Impliquer les parties prenantes (ceux qu’il représente)
• Planifier à moyen/long terme
• Utiliser un outil pour suivre et gérer le backlog
En résumé
The Product Owner is accountable for effective Product
Backlog management, which includes:
• Developing and explicitly communicating the Product
Goal;
• Creating and clearly communicating Product Backlog
items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible
and understood.
En résumé !!!
Le Scrum Master
Les responsabilités d’un S.M.
• Pas de chef de projet dans Scrum ! Le rôle est éliminé.
• Le travail et les responsabilités d’un chef de projet ne

disparaissent pas pour autant dans les projets Scrum.
 une grande partie est dévolue au Product Owner, la partie restante
est laissée à l’équipe et au Scrum Master.
• Un des principes de Scrum est l’auto-organisation

 Pas besoin d’un chef qui assigne le travail à faire à l’équipe.
• Un Scrum Master n’est donc pas un nouveau nom

pour le chef de projet !!!
• Le Scrum Master a pour responsabilité essentielle d’aider
l’équipe à appliquer Scrum et à l’adapter au contexte.
• Il a une grande influence sur la façon de travailler, sur le

processus, comme le Product Owner en a une sur le
produit.
 Le Scrum Master pourrait être qualifié de Process
Owner par équivalence.
e.g. : Faire en sorte que e.g. : Protéger l’équipe

les différentes réunions des interférences
aient lieu et qu’elles se extérieures pendant le
passent dans le respect déroulement d’un sprint
des règles
Compétences souhaitées du S.M.
Compétences souhaitées du S.M.
S.M. : Tâches périodiques
Avant le premier sprint :
• Il s’assure que la logistique est adaptée aux pratiques de travail en
équipe.
Tâches périodiques pendant les sprints
• Il met Scrum en application.
• Il organise et anime les réunions qui constituent le cérémonial d’un
sprint.
• Il fait en sorte que ces réunions aient lieu et qu’elles soient efficaces.
• Il y joue un rôle de facilitateur, littéralement «celui qui facilite les
choses»
Les collaborations du SM
Les services du S.M pour le P.O.
• Le S.M. rend des services au PO sous plusieurs formes,
notamment:
– trouver des techniques pour une gestion efficace du backlog du
produit;
– Communiquer clairement la vision, les objectifs et les user stories à
l'équipe de développement;
– Faire apprendre l'équipe Scrum à créer des entrées du backlog
claires et concises;
– Comprendre la planification de la production à long terme dans un
environnement empirique;
– Comprendre et pratiquer l'agilité;
– Faciliter l’animation des réunions Scrum.
Les services du S.M pour l’équipe
• Le S.M. rend des services à l’équipe sous plusieurs formes,
notamment:
– Coacher l'équipe de développement à l'auto-organisation et la
transversalité;
– Encadrer l'équipe de développement pour créer des produits à haute
valeur ajoutée;
– Eliminer les obstacles au progrès de l'équipe de développement;
– Faciliter et animer les réunions Scrum;
– Entraîner l'équipe de développement dans des environnements
organisationnels dans lesquels Scrum n'est pas encore complètement
adopté et compris.
Les services du S.M pour l’organisation
• Le S.M. rend des services à l’organisation sous plusieurs
formes, notamment:
– Diriger et encadrer l'organisation dans son adoption de Scrum;
– Planifier l’implémentation de Scrum au sein de l'organisation;
– Aider les employés et les intervenants à comprendre et à adopter
Scrum;
– Causer /entraîner des changements qui augmentent la productivité
de l'équipe Scrum;
– Collaborer avec d'autres S.M. pour accroître l'efficacité de
l'application de Scrum dans l'organisation.
Management visuel: Scrum Board
Management visuel: Scrum Board
Choisir le S.M. d’une équipe
Quelques traits permettent de déceler un Scrum Master :
– la capacité à percevoir les émotions dans l’équipe,

– la curiosité et l’envie d’apprendre,
– l’inclination à penser que les gens font de leur mieux
dans leur travail,
– l’envie de changer les choses qui ne vont pas bien,
– l’orientation vers le collectif,
– la prise de risques.
Quelques conseils au S.M.
• Parfaire sa connaissance en Scrum
• Se former au rôle de Scrum Master
• Se faire assister par un coach, en cas de besoin
• Favoriser l’analyse des causes des problèmes
• Favoriser l’auto-organisation de l’équipe
• Maitriser les reportings
En résumé !!!
Les développeurs
Les développeurs
• Une scrum team est composée de développeurs (pas plus que 10)
• Suffisamment grande pour avoir un maximum de compétences et

suffisamment petite pour ne pas perdre trop de temps en coordination.
• Elle s'occupe du « COMMENT » faire (choix techniques, qualité du

code, etc. ), elle s'organise et gère son travail comme elle le souhaite.
• La composition de l’équipe ne doit pas changer pendant un Sprint

Les responsabilités de l’équipe
• Le responsabilité des développeurs est essentielle : ils vont réaliser
le produit, en développant un incrément à chaque sprint.
• Dans Scrum, l’équipe s’organise elle-même et doit avoir toutes les

compétences nécessaires au développement du produit.
 une équipe Scrum est multifonctionnelle.
• C’est l’équipe qui définit elle-même la façon dont elle organise ses
travaux, ce n’est pas le Scrum Master (ni le Product Owner).
• Chaque membre de l’équipe apporte son expertise, la synergie

améliorant l’efficacité globale.
Equipe pluridisciplinaire
La meilleure composition d’une équipe mature de
développement web pourrait correspondre à quelque chose
qui ressemblerait à ceci :
• Développeur frontend
• Développeur backend
• Concepteur graphique et expérience utilisateur
• Testeur
 pluridisciplinaire en cas de besoin!

Equipe pluridisciplinaire
En cas de problèmes d’interface utilisateur en raison de difficultés
techniques et de complexités inattendues, il est possible pour le
développeur backend de donner un coup de main au développeur
frontend.
 Même si le développeur backend n’est pas très entraîné dans le
développement d’interface utilisateur, il/elle devrait avoir quelque
connaissance en développement afin qu’il puisse contribuer dans la
correction des anomalies les plus faciles.
La formation de l’équipe elle-même
est une quête
• Le débutant va commencer certainement en solitaire.
• L’équipe ne se formera pas tout de suite, quelque fois le débutant

commencera avec des membres d’équipes différentes partageant
leurs responsabilités entre différentes équipes.
Qui est votre PO?
Qui fait quoi?
Qui fait quoi?
Sommaire
1. Introduction
6. Scrum of Scrums
93
5 niveaux de planification
La planification Scrum
Product vision
Répond aux questions suivantes:
• Quel problème essayons-nous de
résoudre ?
• Pour qui résolvons-nous ce problème ?
• Quelle solution apportons-nous à ce
problème ?
• Comment allons-nous lancer ce produit ?
(Go-to-market)
• Quel est le modèle économique ?
• Comment allons-nous mesurer le succès
de ce produit ? (revenu, métriques) ?
Product Vision
Product Roadmap
• Un moyen pertinent pour fournir à l’équipe le focus

• Ce n’est pas un engagement …juste un plan
Jan Feb Apr

Mar May Jun
security
Fulfillment
Payments
User Admin Product Admin

Le Backlog de produit - BP
Le Backlog Produit
• Au départ, la difficulté fondamentale est de transformer l’idée
de départ en quelque chose d’utilisable par l’équipe de
réalisation (ER).
• Dans les projets traditionnels, cette transformation se fait

entièrement au début du projet et se concrétise dans un
document, qui décrit :
– ce que va faire le produit,
– quelles sont ses fonctions
– quel est son comportement.
 deviner et imaginer les détails du comportement du
produit avant d’entreprendre aucune action
Le Backlog, la liste unique des stories
• Un backlog = un référentiel des exigences
• Un backlog = Liste ordonnée de toutes les choses à faire.
• Les éléments du Backlog sont appelés des user stories
• .
Le Backlog Produit:
base de la planification
Backlog et roadmap
Backlog de produit
▪ Is an ordered list of everything that might be needed in the product
and is the single source of requirements for any changes to be made to
the product.
▪ A Product Backlog is never complete. The earliest development of it
only lays out the initially known and best-understood requirements.
▪ The Product Backlog evolves as the product and the environment in
which it will be used evolves. As long as a product exists, its Product
Backlog also exists.
▪ The Product Owner is responsible for the Product Backlog,
including its content, availability, and ordering. Maintenance is done
together with the Development Team.
▪ Multiple Scrum Teams often work together on the same product.
Therefore one Product Backlog is used to describe the upcoming
work on the product.
User story
Les user stories
Attributs des PBI
• description,
• ordre,
• valeur et
• estimation
Iceberg du backlog de produit
Item INVEST
PO+Equipe
PO+Stakeholders
~flou
Stakeholders
EPIC vs. Theme
Theme
User stories détaillées: exemple
Ajouter les conditions de satisfaction
INVEST
3C pour les histoires
Product Backlog Refinement
• Les développeurs procèdent au raffinement
du BP, Durant une réunion formelle ou
informelle
• Les étapes sont les suivantes:
– supprimer les histoires non pertinentes
– Créer d’autres histoires qui répondent aux nouvelles
attentes
– Revoir la priorité des histoires
– Affecter les estimations manquantes aux histoires
– Corriger les histoires en fonction des nouvelles
informations identifiées
– Décomposer les histoires ayant un haut niveau de
priorité et qui sont très grandes pour être incorporées
dans un seul sprint
• C’est ajouter les détails, estimations et
ordonner les items.
• Le Product Owner les développeurs
collaborent ensemble.
• La Scrum Team décide du comment et du
quand le raffinement est fait
• Les items peuvent être mis à jour à n’importe
quel moment par le PO.
• Une session mid-sprint avec la Scrum team
pour la raffinement du BP permet de mettre en
place une communication transparente entre
le PO et les développeurs
• Le raffinement de plus de 10% de la capacité
de l’équipe n’est pas souhaitable
• Elle permet de réduire la durée de la réunion
de planification du sprint
INVEST? Not INVEST?
INVEST? Not INVEST?
INVEST? Not INVEST?
INVEST? Not INVEST?
INVEST? Not INVEST?
INVEST? Not INVEST?
Spécification des besoins
• Besoins fonctionnels (Functional requirements- FR)
Chaque Sprint doit donner un increment
• Besoins non fonctionnels (Non-functional requirements- NFR))

Architecture et infrastructure sont des BNF qui font partie de la
DoD.
La notion de priorité dans le Backlog:
Business Value
• Valeur financière
• Valeur business
• Coût de développement et de support
• Les features à haut risque
Les critères de définition des priorités
Parmi les critères qui poussent à donner une grande priorité à
une story :
– La valeur apportée (Business Value)
– MVP: Minimum Viable Product
– La fréquence d’utilisation
– Le risque qu’elle permet de réduire
• L’objectif est de réduire l’exposition au risque le plus rapidement possible.
• Des stories permettant de valider des choix techniques sont toujours prioritaires.
– L’incertitude sur des besoins des utilisateurs qu’elle permettra de
diminuer
• Quand un utilisateur désire une fonctionnalité mais ne sait pas de quelle façon le
service doit être rendu, la solution est de lui montrer rapidement une version pour
obtenir du feedback  s’offrir une occasion d’améliorer le produit.
– La qualité à laquelle elle contribue
• Les travaux visant à garantir la qualité du produit devraient être prioritaires.
– Les dépendances entre stories
Business Value
• Comment prioriser selon la valeur business
• Exemple avec les mêmes durées mais des couts de

retard différents: que choisir en premier
• Exemple avec des durées différentes mais les mêmes

couts de retard: que choisir en premier
Technique de priorisation
• La méthode MoSCoW est une technique visant à
prioriser des besoins ou des exigences
Backlog de produit
Créer votre backlog de produit
• Créer le backolog de produit
• Prioriser
Sommaire
1. Introduction
6. Scrum of Scrums
132
La planification de la release
Définitions
• Une release est la période de temps constituée de sprints
utilisée pour planifier à moyen terme.
• La vélocité est équivalente à la mesure de la partie du

backlog de produit qui est réalisée par l’équipe pendant un
sprint. Les mesures de vélocité sont utilisées pour planifier.
• Un burndown chart est une représentation graphique du

reste à faire dans une période, actualisé aussi souvent que
possible et permettant de montrer la tendance :
– Un burndown chart de sprint est mis à jour quotidiennement,
– Un burndown / burnup chart de release est actualisé à chaque
sprint.
Processus de planification de release
Release 1
Iteration 1 Iteration 2 Iteration 3

Story A – 3 pts Story C – 8 pts Story G – 5 pts
Story B – 2 pts Story E – 2 pts
Story H – 5 pts
Story F – 1 pt
Story D – 5 pts
Étape 1 : Définir le critère de fin de la release
• Pour décider de l’arrêt des sprints et de la fin d’une
release, il existe deux possibilités :
– Finir quand le backlog est vide (c’est du Scrum !!!???)
– Fixer la date à l’avance :
• elle donne un objectif précis, ce qui motive plus l’équipe ;
• elle demande obligatoirement une réflexion poussée sur les priorités
des éléments du backlog par le Product Owner ;
• des éléments du backlog présentant finalement peu d’intérêt ne
seront pas intégrés dans la release ;
• on passe généralement moins de temps à estimer et planifier,
puisque la date de livraison est connue.
• une organisation s’habituera à cette fréquence, qui cadence le travail
de l’équipe mais aussi celui des utilisateurs et de leurs représentants
Étape 2 : Estimer les stories du Backlog
• Chaque story du backlog doit être estimée si on veut en
tenir compte dans la planification.
• L’estimation dont il est question ici est celle relative à sa
taille (en story points) plutôt que la durée ou la charge.
• 3 techniques sont envisageables :
– Triangulation (individuelle ou collective)
– Avis d’experts
– Planning Poker
• L’usage le plus fréquent est de faire une estimation
collective au cours d’une séance appelée planning poker.
La taille
• Elle est exprimée en Story Point.
• C’est une valeur arbitraire qui permet de calculer l’effort

à fournir pour la réaliser et non le temps nécessaire à sa
réalisation
Une mesure relative
• Comme il s’agit de déterminer la complexité d’une User
Story, il est plus simple de la calculer en valeur relative :
“beaucoup plus simple, plus facile, plus difficile, beaucoup
plus difficile”
Planning Poker :
• Le « poker planning » est une pratique Scrum qui permet d’évaluer la
complexité d’un élément du Backlog Produit.
• Il s’agit de réunir l’équipe de réalisation, le Product Owner et le Scrum
Master dans une même salle. On donne à chaque M.E. un jeu de
cartes :
Objectifs du planning Poker :
Problème : le premier qui parle influence les autres ...

En utilisant des cartes, sorties en même temps,

chacun donne librement sa propre estimation, basée sur
sa propre compréhension de la story
En utilisant des cartes, sorties en même temps, chacun donne

librement sa propre estimation, basée sur sa propre
compréhension de la story
Si les écarts sont trop importants, on lance un débat autour des

extrêmes pour comprendre les différents points de vu, puis un
nouveau tour est lancé jusqu’au consensus.
Étape 3 : Définir la durée des sprints
• Les sprints doivent avoir une durée fixe.
• La durée est définie en fonction :
- de vos besoins en réactivité
- des besoins en montée en puissance de l’équipe
• Les sprints peuvent avoir une durée de 1 à 4 semaines.
Le Sprint
• Le Sprint est le cœur de Scrum,
• Durée: 1 mois ou moins, au cours de laquelle un Incrément publiable
du produit est créé. Publiable ne veut pas nécessairement dire mettre
en production, le produit délivré est au moins utilisable.
• Un nouveau Sprint commence dès la conclusion du Sprint précédent.
• L'objectif du Sprint est fixe. Le périmètre peut-être clarifié et négocié
entre le PO et la DT, mais les changements qui remettent en cause
l'objectif du Sprint ne sont pas permis.
• Seul le PO a le pouvoir d'annuler un Sprint avant son
échéance. Cette action étant bouleversante pour l'équipe
et chronophage, les annulations sont très rares.
• Le Sprint est le conteneur pour tous les autres
événements Scrum.
Comment choisir?
• Les sprints courts sont bénéfiques: Ils autorisent l'entreprise à être “agile”,
c'est-à-dire à changer souvent de direction.
 Sprint court = cycle de feedback court = des livraisons plus fréquentes =
plus de feedback des clients = moins de temps passé à courir dans la
mauvaise direction = apprendre et améliorer plus rapidement, etc.
• Les longs sprints:

 L'équipe a plus temps pour monter en puissance,
 ils ont plus de temps pour récupérer des problèmes et parvenir tout de même
à atteindre le but du sprint,
 il y a moins de surcharge en terme de réunions de planning de sprint, de
démonstrations, etc.
Durées de releases et de sprints usuelles

Étape 4 : Estimer la capacité de l’équipe
• La vélocité, mesure de la partie de backlog réalisée par
l’équipe pendant un sprint, se calcule juste après la
démonstration lors de la revue de sprint.
Velocity is an optional, but often used, indication of the amount of

Product Backlog turned into an Increment of product during a
Sprint by a Scrum Team
Étape 4 : Estimer la capacité de l’équipe - Vélocité
Étape 5 : Produire le plan de release
• Considérer le backlog priorisé et estimé.
• Commencer par le premier sprint de la release.
• Y associer les stories en commençant par les plus
prioritaires.
• Continuer dans ce sprint en additionnant la taille en points
des stories jusqu’à arriver à la capacité de l’équipe
(vélocité)
• Quand on y arrive, passer au sprint suivant.
Exemple : On considère que la vélocité moyenne est de dix,
 Pour les sprints à planifier, dix points de backlog sont affectés en
suivant les priorités.
Dans certains cas, une intervention manuelle s’avère
quand même utile :
– si on ne tombe pas juste sur la capacité en ajoutant une story au
sprint : il faut décider si on se place plutôt en dessous, en dessus
ou si on prend une story moins prioritaire mais qui permet d’être
plus proche de la capacité ;
– parce que la vue du plan de release pousse à faire des
ajustements : l’attribution des priorités est tellement délicate qu’une
consultation du contenu des sprints amène parfois l’équipe à faire
de nouveaux arbitrages dans le plan de release.
Un plan de release
Burndown chart de release
• Un burndown de release est un indicateur graphique basé sur la
mesure de ce qui reste à faire.
• Un point dans le graphe est ajouté pour chaque sprint.
• Pour l’obtenir il faut donc une liste de ce qui reste à faire et une mesure
de la taille de chaque élément, ce qu’on trouve dans le backlog de
produit.
• À quoi sert le burndown chart de release ?

– à montrer l’avancement réel, en tout cas le meilleur qu’on ait, puisqu’il est
basé sur la distinction entre ce qui est complètement fini et ce qui reste.
– à montrer la tendance et se poser des questions sur la façon de continuer.
• Si la représentation du burndown n’est pas évidente, on peut aussi
opter pour un burnup chart
Burndown de la release/sprint
Burnup
Backlog de produit
Les évènements dans Scrum
Les évènements dans Scrum
• Prescribed events are used to create regularity and to minimize the
need for meetings not defined in Scrum.
• All events are time-boxed, such that every event has a maximum
duration.
• Other than the Sprint itself, which is a container for all other events,
each event in Scrum is a formal opportunity to inspect and adapt
something.
• These events are specifically designed to enable critical transparency
and inspection.
Rôle du SM durant les évènements
• Le Scrum Master n’est pas obligé
d’être présent aux différents
événements.
• Il est dans l’obligation de s’assurer

que tous ces évènements vont se
dérouler dans de bonnes conditions
dans le respect des blocs de temps
alloués.
La réunion de planification de
sprint (sprint planning
meeting)
Sprint planning
Le planning de sprint
• Le travail du sprint appartient à l’équipe : ce n’est pas un chef qui définit
ce qu’il y a à faire, c’est l’équipe qui s’organise elle-même.
• Au-delà de sa fonction première de planification, la réunion est un rituel

qui prépare l’équipe à travailler de façon collective pendant le sprint
• Que va t-on developer durant le sprint afin de donner naissance à

l’incrément?
• Comment le faire afin de livrer l’incrément demandé?

Sprint backlog
• Is the set of Product Backlog items selected for the Sprint, plus a
plan for delivering the product Increment and realizing the Sprint
Goal.
• To ensure continuous improvement, it includes at least one high

priority way in which the team works, identified in the previous
Retrospective meeting.
• Only the Development Team can change its Sprint Backlog during
a Sprint.
• The Sprint Backlog is a highly visible, real-time picture of the work that
the Development Team plans to accomplish during the Sprint, and it
belongs solely to the Development Team.
Sprint backlog
Sprint backlog
• The Sprint Backlog is composed of the Sprint Goal (why), the
set of Product Backlog items selected for the Sprint (what), as
well as an actionable plan for delivering the Increment (how).
• The Sprint Backlog is a plan by and for the Developers. It is a
highly visible, real-time picture of the work that the Developers
plan to accomplish during the Sprint in order to achieve the
Sprint Goal.
• Consequently, the Sprint Backlog is updated throughout the
Sprint as more is learned.
• It should have enough detail that they can inspect their
progress in the Daily Scrum.
Tableau des tâches mural
• Il est élaboré lors de la réunion de planification du sprint.
• Pour chaque story sélectionnée, l’équipe identifie les
tâches correspondantes.
• Sur le tableau, les stories et les tâches sont placées avec
des Post-it.
• L’état des tâches est reconnu selon la place de la tâche
dans des zones représentant chaque état : à faire, en
cours et finie.
Faire de la planification de sprint
• Préparer le backlog de produit en anticipation
• Laisser l’équipe décider du périmètre en collaboration
avec le PO
• Laisser l’équipe décomposer les stories en tâches courtes
• Prendre un engagement raisonnable
• Garder du mou dans le plan de sprint
– Pour les incertitudes dans les estimations sur les tâches.
– Pour les impondérables susceptibles de se produire.
 prévoir une proportion < ou = à 20% de mou (temps non affecté)
• Faire de la conception tout au long des sprints

Définition de « Terminé – Fini – Done »
Définition de « fini »
173/75
Exemple de Définition de « Done »
• Code produced (all 'to do' items in code completed)
• Code commented, checked in and run against current version in
source control
• Peer reviewed (or produced with pair programming) and meeting
development standards
• Builds without errors
• Unit tests written and passing
• Deployed to system test environment and passed system tests
• Passed UAT (User Acceptance Testing) and signed off as meeting
requirements
• Any build/deployment/configuration changes implemented/
documented/ communicated
• Relevant documentation/diagrams produced and/or updated
• Remaining hours for task set to zero and task closed
http://www.agile-software-development.com/2007/07/definition-of-done-10-point-
checklist.html
DoD selon le Scrum Guide
• “The Definition of Done is a formal description of the state of the
Increment when it meets the quality measures required for the
product.
• The moment a Product Backlog item meets the Definition of Done, an
Increment is born.
• The Definition of Done creates transparency by providing everyone a
shared understanding of what work was completed as part of the
Increment.
• If the Definition of Done for an Increment is part of the standards of
the organization, all Scrum Teams must follow it as a minimum. If it is
not an organizational standard, the Scrum Team must create a
Definition of Done appropriate for the product.”
Plusieurs équipes sur un même BP
et crée un incrément
Incrément: résultat du sprint
Sprint backlog
Attention!!!!
• Durant les sprints, la capacité de l’équipe doit augmenter.
 bon SM, bon PO, équipe motivée et engagée
• La capacité peut diminuer à cause des dettes techniques:

- Bug problème au niveau d’une tâche:
– Ne doit pas être réintégrer dans le BP
– Ne s’estime pas
– L’équipe assume!
- Dysfonctionnement  problème au niveau d’une ou
plusieurs US
– Il faut l’intégrer dans le BP
– Sa complexité sera plus imprtante par rapport à sa première estimation
179
Le Scrum quotidien ou
La Mêlée quotidienne
Une réunion quotidienne
Une réunion quotidienne
• Le scrum quotidien est un point de rencontre où tous les membres de
l’équipe répondent à trois questions simples et actualisent le plan de
sprint :
– Présenter ce qui a été fait : Ce que j’ai fait depuis le dernier scrum afin
d’atteindre le but du sprint ?
– Prévoir ce qui va être fait : Ce que je prévois de faire jusqu’au prochain
scrum afin d’atteindre le but du sprint ?
– Identifier les obstacles : Quels sont les obstacles qui freinent NOTRE
travail afin d’atteindre le but du sprint?
• Son but principal est d’optimiser la probabilité que l’équipe atteigne
les objectifs du sprint.
• Les moyens pour atteindre ce but consistent en :
– Éliminer les obstacles nuisant à la progression de l’équipe.
– Garder l’équipe concentrée sur l’objectif du sprint.
– Évaluer l’avancement du travail pour le sprint en cours.
– Communiquer objectivement sur l’avancement.
Réussir un Scrum quotidien
Les signaux d’avertissement
187
??? Non !!!
188
??? Non !!!
189
La revue de Sprint (sprint
revue)
La revue de Sprint
• L’un des principes des méthodes agiles :
« pour connaître l’avancement d’un développement, il vaut
mieux se baser sur du logiciel fonctionnel plutôt que sur de la
documentation ».
• Dans un développement de logiciel, on va montrer du code

qui marche  démonstration de l’incrément de produit réalisé
pendant le sprint.
 favoriser les notions de transparence, inspection et

adaptation.
La revue de Sprint
• Elle se déroule à la fin du sprint afin
d’inspecter l’increment et adapter le BP si
c’est nécessaire
• Durant la Sprint Review, la Scrum Team

et les stakeholders collaborent sur ce qui a
été fait dans le sprint.
• C’est une réunion informelle, et la

présentation de l’increment est faite pour
avoir un feedback et une meilleure
collaboration
• Timebox: 4 heures pour des sprints de 4

semaines
Processus type
• Attendees include the Scrum Team and key stakeholders invited by the Product
Owner;
• The Product Owner explains what Product Backlog items have been “Done” and
what has ▪ not been “Done”;
• The Development Team discusses what went well during the Sprint, what problems
it ran into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and answers
questions about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects
likely target and delivery dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review
provides valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed
what is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated releases of functionality or capability Of the product.
La rétrospective de Sprint
La rétrospective de Sprint
• L’un des principes des méthodes agiles :
«À intervalles réguliers, l’équipe réfléchit à comment devenir
plus efficace, puis adapte et ajuste son comportement en
conséquence».
• Cette réunion permet à l’équipe d’optimiser son

auto-évaluation en effectuant une rétrospective du sprint :
 faire ressortir les éléments qui ont bien fonctionné et
ceux qui restent à améliorer.
 des actions concrètes sont alors proposées pour le sprint
suivant
Une pratique d’amélioration continue
• La rétrospective constitue un moment
particulier où l’équipe Scrum s’arrête de
produire, prend le temps de réfléchir et parle de
ses expériences, avec l’objectif de :
– capitaliser sur les pratiques qui ont marché,
– éviter de refaire les mêmes erreurs,
– partager différents points de vue,
– permettre au processus de s’adapter aux
nouvelles avancées dans la technologie utilisée
pour développer.
• Elle dure trois heures au maximum (sprint
d’un mois) et a lieu entre la revue et la
planification du sprint suivant.
• La réunion est, généralement, animée par le
ScrumMaster
Une pratique d’amélioration continue
• Une rétrospective représente pour les participants une possibilité
d’apprendre comment s’améliorer.
• L’idée est que ceux qui réalisent sont les mieux placés pour savoir
comment progresser.
• L’objectif est l’apprentissage, et non la recherche de fautes.
• L’équipe est impliquée dans la mesure où chacun doit :

– comprendre le besoin d’amélioration,
– concevoir les améliorations,
– s’approprier les améliorations,
– être motivé pour s’améliorer.
Étapes de la rétrospective
• Étape 1 : Créer un environnement propice à
l’expression
• Il s’agit de s’assurer que tout le monde se sent en confiance et
pourra s’exprimer librement pendant la réunion.
• « Indépendamment de ce que nous allons découvrir

aujourd’hui, nous comprenons et nous croyons vraiment que
chacun a fait de son mieux, en fonction de ses connaissances,
de ses compétences et de ses capacités, des ressources
disponibles et de la situation courante. »
• Si l’animateur constate que quelqu’un n’est pas en capacité de

s’exprimer librement, la rétrospective ne peut pas avoir lieu
• Étape 2 : Collecter les informations sur le sprint passé
• Avant de chercher à améliorer les pratiques, il convient de
collecter le ressenti des participants sur ce qui s’est passé
pendant le sprint qui s’achève.
• L’approche basique consiste à poser des questions à

chaque participant, de façon un peu similaire à ce qui est
fait dans le scrum quotidien :
– Qu’est-ce qui a bien fonctionné ?
– Qu’est-ce que nous pouvons améliorer ?
– Qu’est-ce qui s’est mal passé ?
Collecte des informations
• Étape 3 : Identifier des idées d’amélioration
• L’objectif d’une rétrospective n’est pas seulement de
poser des questions sur le passé, mais surtout celui
d’apporter des réponses concrètes qui seront mises en
place dans la prochaine itération.
• Les informations collectées dans l’étape précédente sont

complétées avec les idées d’amélioration proposées par
l’équipe.
• Étape 4 : Regrouper les idées
• Les informations sont regroupées en catégories (5 – 10).
• Les catégories correspondent en général à des pratiques
agiles et aux outils qui les supportent.
• Chacune est nommée pour que tout le monde l’identifie
clairement.
• Étape 4 : Définir l’amélioration prioritaire
• Il s’agit de définir sur quelle pratique va être porté l’effort
d’amélioration.
• La technique de sélection doit permettre la participation de

toute l’équipe, avec par exemple un système de votes.
• Étape 5 : Adapter Scrum pour le prochain sprint
• Il s’agit de définir les actions concrètes qui vont être
menées lors du prochain sprint.
• Les actions sont identifiées par l’équipe, en réfléchissant à

toutes les tâches nécessaires.
• À la fin de la réunion, il est conseillé que l’équipe revoie sa

signification de « Fini – Done »
Résultats de la rétrospective
• Le résultat de la rétrospective est la liste des actions qui ont été
décidées. On peut classer les actions selon leur orientation :
– celles dirigées vers les personnes et leur façon d’appliquer les pratiques,
– celles orientées vers les outils à installer ou à adapter,
– celles axées sur l’amélioration de la qualité.
• Par exemple, les actions impactant les personnes sont :
– limiter le scrum à 15 minutes,
– faire une heure de travail en binôme tous les jours,
– modifier la façon de prendre en compte les bugs...
Exemple : la limitation des scrums quotidiens à un quart d’heure est
l’amélioration choisie par l’équipe.
 Les actions identifiées sont :
• apporter un minuteur,
• annoncer le temps écoulé,
• afficher la durée tous les jours.
La rétrospective
• The purpose of the Sprint Retrospective is to plan ways to
increase quality and effectiveness.
• The Scrum Team identifies the most helpful changes to
improve its effectiveness.
• The most impactful improvements are addressed as soon
as possible: they may even be added to the Sprint
Backlog for the next Sprint.
• The Sprint Retrospective concludes the Sprint.
Retrospective
Sommaire
1. Introduction
6. Scrum of Scrums
209
SM et PO peuvent travailler avec
plusieurs équipes
Scrum of Scrums
Scaling Scrum
Maintenance et gestion des bugs
• Il n’y a pas de vraie phase de maintenance
• Gestion des bugs
– Défaut sur une story considérée comme finie
• Ce sont les défaut s découverts sur une story développée dans un sprint
précédent et qui a été considérée comme finie.
• Ou, les défauts qui portent sur des parties développées avant que le projet
mette en place un processus agile.
• Un défaut enlève de l’utilité à une story selon sa gravité :
– Un défaut critique empêche le fonctionnement d’une ou plusieurs
stories,
 traitement prioritaire + ajout de tâches dans le plan de sprint
– Un défaut majeur ne permet pas un fonctionnement normal et fait perdre
une grande partie de l’utilité à la story  une nouvelle entrée dans le backlog
produit + traitement au prochain sprint
– Un défaut mineur fait perdre un peu de valeur à une story en rendant son
utilisation plus difficile  une nouvelle entrée dans le backlog produit
213
Sommaire
1. Introduction
6. Scrum of Scrums
214
Conclusion générale
Waterfall vs. Agile

Scrum RSK

Transféré par

Droits d'auteur :

Formats disponibles

Scrum RSK

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Scrum RSK

Transféré par

Droits d'auteur :

Formats disponibles

La méthode Agile

Dr. Rim Samia Kaabi

2. Méthodes traditionnelles ou méthodes agiles ?

3. Les responsabilités SCRUM

4. Les artéfacts SCRUM

5. Les évènements SCRUM

2. Méthodes traditionnelles ou méthodes agiles ?

3. Les responsabilités SCRUM

4. Les artéfacts SCRUM

5. Les évènements SCRUM

• Pour répondre à un certain nombre de problèmes

• Les causes 100

– Machines puissantes à coûts modérés

– Demande et Complexité croissante

Initiation Planification, Pilotage & Suivi

2. Méthodes traditionnelles ou méthodes agiles ?

3. Les rôles SCRUM

4. Les artéfacts SCRUM

5. Les réunions SCRUM

 Définir et réserver les moyens nécessaires

• Une alternative : les méthodes AGILES!!!

In a business context, agility is the ability of an organization to rapidly

Agile organizations prefer an iterative and incremental delivery

84% le travail est plus facile et

77% plusss de transparence

71% Faster Market solutions

Simplicité - l'art de Architectures,

– Adaptatives plutôt que prédictives

– Orientées vers des personnes plutôt que vers les processus

• Un spécialiste des processus parlerait, pour Scrum, de pattern de

• Scrum a été conçu pour améliorer grandement la

Scrum Animateur, facilitateur d'une équipe Scrum. Littéralement le maître de Scrum.

• Read the Scrum Guide!

• Chaque sprint a pour objectif de réaliser un incrément

2. Méthodes traditionnelles ou méthodes agiles ?

3. Les responsabilités SCRUM

4. Les artéfacts SCRUM

5. Les évènements SCRUM

1. Fournir une vision partagée du produit :

• Le P.O. est responsable du backlog et y contribue de façon régulière.

• En plus de son travail pour le sprint courant, il s’occupe aussi des

• L’ordre de réalisation définit le cycle de vie du produit. Cette vie est

• Le P.O. définit l’objectif d’une release et prend les décisions sur le

• Quelqu'un qui a été Analyste Métier (Business Analyst)

• En effet, cette personne doit être :

• Le travail et les responsabilités d’un chef de projet ne

• Un des principes de Scrum est l’auto-organisation

• Un Scrum Master n’est donc pas un nouveau nom

• Il a une grande influence sur la façon de travailler, sur le

e.g. : Faire en sorte que e.g. : Protéger l’équipe

– la capacité à percevoir les émotions dans l’équipe,

• Suffisamment grande pour avoir un maximum de compétences et

• Elle s'occupe du « COMMENT » faire (choix techniques, qualité du

• La composition de l’équipe ne doit pas changer pendant un Sprint

• Dans Scrum, l’équipe s’organise elle-même et doit avoir toutes les

• Chaque membre de l’équipe apporte son expertise, la synergie

 pluridisciplinaire en cas de besoin!

• L’équipe ne se formera pas tout de suite, quelque fois le débutant

2. Méthodes traditionnelles ou méthodes agiles ?