EXIN Agile Scrum

Manuel de Base

Par Nader K. Rad, Frank Turley

PagErreur ! Référence de lien hypertexte non valide.

EXIN Agile Scrum
Manuel de Base

EXIN Agile Scrum Manuel de Base

Par Nader K. Rad, Frank Turley

© 2014, Nader K. Rad et Frank Turley

Tous droits réservés. À l'exception de brefs passages et

citations à des fins de révision ou de commentaire, aucune
partie de cette publication ne peut être reproduite ou
transmise sous quelque forme ou par quelque moyen que
ce soit sans le consentement préalable des auteurs.

Page 1
EXIN Agile Scrum
Manuel de Base

Table des matières

A propos des auteurs ................................................................................................................4

Certification EXIN Agile Scrum Foundation...............................................................................5
Agility Concept ..........................................................................................................................7
Project Delivery Method and Lifecycle .................................................................................7
Agile Manifesto ....................................................................................................................10
Agile Principles .....................................................................................................................12
When Can We Use Agile? ....................................................................................................14
Managing the Scope ............................................................................................................16
Type of Scope items .........................................................................................................16
Adaptation of the Scope .................................................................................................. 17
Functional vs. Non-Functional Features ..........................................................................18
Bugs .................................................................................................................................. 19
Spikes ...............................................................................................................................19
MoSCoW Prioritization.....................................................................................................20
Keeping the Scope Dynamic.............................................................................................21
Product Scope in Agile Environments ..............................................................................22
The Timebox Concept ..........................................................................................................23
Planning Onion.....................................................................................................................24
Agile Practices ......................................................................................................................25
Pair Programming ............................................................................................................25
Bus Factor ....................................................................................................................25
Test-Driven Development ................................................................................................26
Continuous Integration ....................................................................................................26
Continuous Refactoring ................................................................................................... 27
Collective Code Ownership ..............................................................................................27
Sustainable Pace ..............................................................................................................28
Scrum Framework ....................................................................................................................30
Quick Overview of the Scrum Framework ...........................................................................30
Scrum Roles..........................................................................................................................32
Scrum Team .....................................................................................................................32
Role 1: The Product Owner ..............................................................................................34
Role 2: The Scrum Master ................................................................................................36
Role 3: The Development Team.......................................................................................37
Other Roles ......................................................................................................................38
Who Is the Project Manager? ..........................................................................................38
Pigs and Chickens .............................................................................................................38
Scrum Events........................................................................................................................39
Introduction to Scrum Events ..........................................................................................39
Timeboxing...................................................................................................................39
Suitable Workspace .....................................................................................................40
Osmotic communication ..............................................................................................40
Managing Distributed Teams .......................................................................................40
Event 1: The Sprint ...........................................................................................................40
Setting the Duration of the Sprints ..............................................................................42
Overtime Work, Buffers, etc. .......................................................................................42
Canceling Sprints..........................................................................................................42
Sprint 0 .........................................................................................................................43

Page 2
EXIN Agile Scrum
Manuel de Base

Event 2: Sprint Planning ................................................................................................... 43

Event 3: Daily Scrum ........................................................................................................46
Event 4: Sprint Review .....................................................................................................47
Event 5: Sprint Retrospective ..........................................................................................48
Activity: Product Backlog Refinement .............................................................................49
Slack ................................................................................................................................. 49
Scrum Artifacts.....................................................................................................................49
Artifact 1: Product Backlog ..............................................................................................50
Product Backlog Items ................................................................................................. 51
User Stories ..............................................................................................................51
Epic User Stories ......................................................................................................52
Themes.....................................................................................................................52
Estimating ....................................................................................................................52
Story Points ..............................................................................................................52
Planning Poker .........................................................................................................53
Triangulation ............................................................................................................54
Triangulation Board ................................................................................................. 55
Affinity estimation ................................................................................................... 55
Ideal hours / Ideal days ............................................................................................56
Re-estimating ...........................................................................................................56
Ordering the Product Backlog Items............................................................................57
Release Planning ..........................................................................................................58
Artifact 2: Sprint Backlog ................................................................................................. 59
Velocity ........................................................................................................................60
Artifact 3: Increment ........................................................................................................61
Artifact 4: Definition of “Done” .......................................................................................61
Agile Documentation ................................................................................................... 62
Agile Testing .................................................................................................................63
Artifact 5: Monitoring Progress toward a Goal................................................................63
Information Radiators .................................................................................................. 63
Burn-Down Charts....................................................................................................64
Burn-Down Bars .......................................................................................................66
Burn-Up Charts ........................................................................................................67
Cumulative Flow Diagrams ......................................................................................68
Niko-niko calendar ................................................................................................... 70
Artifact 6: Monitoring Sprint Progress .............................................................................71
Scaled Scrum ........................................................................................................................71
Roles ................................................................................................................................. 72
Product Ownership ..........................................................................................................72
Scrum of Scrums ..............................................................................................................73
Synchronization................................................................................................................74
Splitting Teams.................................................................................................................74
Contract Types and Scrum ................................................................................................... 75
Scrum Prerequisites .............................................................................................................75
Kanban .....................................................................................................................................78
ScrumBan ................................................................................................................................. 84
Le Voyage Commence ..............................................................................................................87

Page 3
EXIN Agile Scrum
Manuel de Base

A propos des auteurs

Nader K. Rad est consultant en gestion de projet, auteur et formateur

à Management Plaza. Sa carrière a débuté en 1997 et il a été impliqué
dans de nombreux projets dans différentes industries. Il a conçu un
certain nombre de cours de gestion de projet, préparé un certain
nombre de matériels d'apprentissage en ligne et écrit plus de 40
livres. Il a également rédigé de nombreux articles pratiques sur les
concepts et normes de gestion de projet, les logiciels de planification,
la planification du temps, etc.
Il est certifié PMP®, PRINCE2® Practitioner, MoP® Practitioner,
MSP® Foundation, MoV® Foundation, M_o_R® Foundation, P3O®
Foundation, AgilePM® Practitioner, CSM®, PSM I, PSPO I, EXIN Agile
Scrum Foundation, et ITIL® Foundation.
Il est également certifié PRINCE2®, MoP® et Agile Scrum Trainer.

En savoir plus sur l'auteur: http://nader.pm

Site web de l’auteur: http://www.mgmtplaza.com
Profile LinkedIn de l’auteur: be.linkedin.com/in/naderkrad

Frank Turley est chef de projet depuis plus de 15 ans. Il est praticien
PRINCE2® et Scrum Master et également formateur et coach PRINCE2
et en gestion de projet. Il a écrit un certain nombre de livres liés à
PRINCE2® et à la gestion de projet et est surtout connu
dans le monde PRINCE2 pour son travail dans la création des plus
populaires matériel d'autoformation PRINCE2 comprenant:
• Le manuel de formation PRINCE2 Foundation et le cours vidéo
• Le manuel de formation PRINCE2 Practitioner
• Exemplaire de projet PRINCE2

En savoir plus sur l'auteur: http://mgmtplaza.com/frank-turley

Site web de l’auteur: http://www.mgmtplaza.com
Profile LinkedIn de l’auteur: http://linkedin.com/in/frankturley

Page 4
EXIN Agile Scrum
Manuel de Base

Certification EXIN Agile Scrum Foundation

EXIN Agile Scrum Foundation est une certification professionnelle centrée sur le concept
Agility et le framework Scrum qui est utile pour ceux qui sont impliqués dans des
environnements Agile ou ceux qui envisagent d’y migrer et qui souhaitent prouver leurs
connaissances. Le programme de certification est défini et fourni par EXIN, l'un des
principaux fournisseurs mondiaux de certification et d'accréditation en gestion de
l'information indépendante.

Informations générales sur l'examen:

• Prérequis: aucun
• Type de questions: choix multiples
• Nombre de questions: 40
• Note de passage: 65%
• Document autorisé: non

Comme il n'y a pas de prérequis pour l'examen et que vous pouvez vous inscrire et passer
l'examen en ligne, il est vraiment accessible à tous, en particulier à ceux qui préfèrent auto-
étudier.

Ce livre couvre presque tout ce que vous devez savoir pour l'examen. Vous passeriez
facilement l'examen en lisant ce livre entièrement et attentivement. Cependant, le
concept d'agilité est large et vous pouvez toujours rencontrer une question sur un sujet
qui n'est pas abordé dans ce manuel de formation.

Ce livre est approuvé par EXIN comme ressource pour l'examen EXIN Agile Scrum Foundation.

Vous pouvez en savoir plus sur l'examen ici:

https://www.exin.com/NL/en/exams/&exam=exin-agile-scrum-foundation

Vous pouvez passer un exemplaire d'examen Agile Scrum Foundation via la même page
Web lorsque vous êtes prêt.

Page 5
EXIN Agile Scrum
Manuel de Base

1
Concept d’Agilité

Page 6
EXIN Agile Scrum
Manuel de Base

Concept d’Agilité

Le mot «agile» est un adjectif, signifiant: se déplacer rapidement et facilement, ou penser

rapidement et de manière intelligente (dictionnaire Oxford Advanced Learner). Cependant,
«Agile» (avec un A majuscule) est utilisé pour désigner un groupe de cadres de travail
utilisés pour le développement et la gestion d’initiatives1. L'objectif principal des cadres de
travail Agile est de rendre le développement plus rapide et plus fluide, et de créer un
résultat plus satisfaisant pour le client.
Presque tout le monde dans le secteur informatique a entendu parler d'Agile et est prêt à
l'essayer; en tout cas eux et leurs clients sont prêts pour un tel changement. Il y a même des
clients qui s'attendent à ce que vous soyez Agile, alors qu'ils n'acceptent pas certaines de
ses conséquences (par exemple, le manque de documentation en amont).

Alors, commençons ce livre en passant en revue le concept d'Agilité pour créer une base
solide avant de discuter d'un cadre de travail réel dans le chapitre suivant.

Méthode de livraison du projet et cycle de vie

Les processus de développement communs pour un projet informatique sont les suivants:

• Analyser
• Concevoir
• Construire
• Intégrer
• Tester

Il existe différents processus formalisés pour le développement de projets informatiques,

mais ils sont tous similaires aux processus ci-dessus. Certains processus peuvent être
nommés différemment, fractionnés ou fusionnés, mais le concept est le même. Ces
processus sont nécessaires pour chaque projet informatique, quel que soit le cycle de vie
utilisé: Agile ou traditionnel. Le point principal ici est comment nous organisons
les processus, ce qui crée différents cycles de vie. Certains cycles de vie sont Agiles et
d'autres non.

Examinons donc les différentes façons dont nous pouvons concevoir le cycle de vie du
développement en fonction des processus de développement standard.

Une façon d'exécuter les processus consiste à les exécuter les uns après les autres, comme
illustré dans la figure suivante.

1
“Initiative” est le terme utilisé pour désigner les projets et les programmes. Un programme est une
Initiative qui est focalisée sur la création d’un résultat au lieu d’un produit. Les programmes sont faits
de multiples projets liés.

Page 7
EXIN Agile Scrum
Manuel de Base

Dans ce cycle de vie, nous commençons par le premier processus et y consacrons

suffisamment de temps jusqu'à ce qu'il soit terminé. Ensuite, nous clôturons le processus et
passons au suivant. Chaque processus crée un document de sortie: un document, un code
ou un nouvel état dans le code.
Plan de haut niveau Plan détaillé
du projet du projet

Analyser Concevoir Construire Intégrer Tester

Prévision du périmètre Prévision de Produit

l’architecture

La première étape (Analyser) consiste à spécifier les exigences et à définir le périmètre du

projet. Il est très important d'avoir un périmètre bien défini pour éviter des problèmes
ultérieurs dans les environnements traditionnels. La donnée de sortie est un document qui
peut être appelé «Spécifications des exigences» ou quelque chose de similaire.
La deuxième étape (Concevoir) consiste à concevoir l'architecture de la solution, résultant en
un document qui pourrait être appelé «Architecture de la solution».
La troisième étape (Construire) consiste à construire le logiciel dans son intégralité. Ensuite,
dans la quatrième étape, le code est intégré et enfin testé et débogué dans la dernière
étape.
C'est la manière traditionnelle de développer des solutions informatiques et elle est encore
couramment utilisée dans de nombreuses organisations aujourd'hui. Elle est souvent
appelée le modèle Waterfall (cascade). La principale caractéristique de ce cycle de vie est
que tout est défini avant le début du développement et qu'il existe une séparation claire
entre les processus. Il peut parfois y avoir un chevauchement entre les processus, mais il
s'agirait toujours d'un cycle de vie en cascade.
Cette caractéristique qui consiste à tout définir à l'avance et d'essayer de s'y tenir est
appelée prédictive, de sorte que le modèle que nous venons de décrire est un cycle de vie
prédictif. Le modèle Waterfall est un nom commun pour les cycles de vie prédictifs dans le
monde du développement informatique.
Dans un cycle de vie prédictif, le projet est exécuté étape par étape. Chaque étape est
dédiée à un certain concept du projet et tout est conçu et planifié en amont. Ce cycle de vie
est idéal pour de nombreux projets, tels que la construction d'une maison, d'un hôpital ou
d'un aéroport. Cependant, lorsqu'il s'agit de projets informatiques, il est très difficile
d'utiliser un tel système car le client ne sait généralement pas exactement ce qu'il veut, et
par conséquent, il continue de changer les exigences tout au long du projet. Pensez à un
projet de construction d'un hôpital: il peut faire face à de nombreux changements, mais est
il possible que vous vous retrouviez avec un parc à thème au lieu d'un hôpital? Bien sûr que
non. Cependant, il est tout à fait possible que les projets informatiques commencent à créer
quelque chose comme un «hôpital» et se retrouvent avec quelque chose comme un «parc à
thème»!

Page 8
EXIN Agile Scrum
Manuel de Base

Le problème est que les clients ne savent pas ce qu’ils veulent, jusqu’à ce qu’ils voient le
logiciel oprérationnel, ce qui est produit très tard dans le cycle de vie prédictif (à la fin du
projet). Nous pouvons utiliser le cycle de vie suivant pour éviter ce problème:

Analyser Analyser Analyser Analyser Analyser Analyser

Concevoir Concevoir Concevoir Concevoir Concevoir Concevoir
Construire Construire Construire Construire Construire Construire
Intégrer Intégrer Intégrer Intégrer Intégrer Intégrer
Tester Tester Tester Tester Tester Tester

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6

Incrément Incrément Incrément Incrément Incrément Incrément

(produit) (produit) (produit) (produit) (produit) (produit)

Nous utilisons un certain nombre d'itérations dans ce cycle de vie, appelées Sprints dans
Scrum. Nous exécutons tous les processus de développement sur une partie du produit à
chaque itération. La principale raison d'utiliser des cycles de vie itératifs est d'avoir des
solutions intermédiaires à la fin de chaque itération, de les montrer au client, de recevoir ses
commentaires, d'appliquer ces commentaires aux itérations suivantes et ainsi de réduire la
quantité de retouches dans les itérations ultérieures.
Nous avons donc des solutions intermédiaires (incréments) en cours de route et nous
pouvons recevoir des commentaires utiles après chaque itération. Nous souhaitons recevoir
des retours le plus rapidement possible afin de les appliquer dans les prochaines itérations
du projet. Une conséquence est que le nombre et le contenu des éléments de construction
sont dynamiques. Ainsi, au lieu de créer une spécification complète des exigences avant de
tout concevoir et de tout construire, nous commençons à incrémenter et à itérer avec un
nombre limité de pièces de construction et à laisser les autres parties du périmètre se
former au fur et à mesure que le projet avance. C'est ce qu'on appelle un cycle de vie
adaptatif; un cycle de vie qui développe la solution finale de manière itérative et
incrémentale, par adaptation.
Ce que nous appelons Agile, est techniquement équivalent à l'utilisation de cycles de vie
adaptatifs. La cascade ou les méthodes traditionnelles utilisent un cycle de vie prédictif
comme mentionné précédemment dans ce chapitre.
Notez qu'un cycle de vie adaptatif n'est pas seulement le processus de division du
développement des fonctionnalités en plusieurs étapes; il se concentre sur la limitation
du plan à quelques itérations dans un proche avenir et sur l'utilisation des données de
sortie de chaque itération pour planifier un peu plus loin dans l'avenir.
Un autre point important concernant les cycles de vie adaptatifs est que nous
n'exécutons pas une mini-cascade à l'intérieur de chaque itération. Une mini-cascade
exécute tous les processus de développement pour tous les éléments d'itération en
même temps: spécifie l'itération, puis la conçoit, puis la construit, etc. Nous utilisons des
itérations mini-agiles à l'intérieur, qui se concentrent sur des fonctionnalités uniques à la
fois, et exécute tous les processus de développement pour eux séparément.

C
h
a
q
Page 9
EXIN Agile Scrum
Manuel de Base

Chaque processus Fontionnalité 1

de développement Fontionnalité 2
Fontionnalité 3 Mini-Waterfall (faux)
est conduit une seule Fontionnalité 4
fois pour toutes les Fontionnalité 5
fonctionnalités.

Chaque processus de Fontionnalité 1

développement est Fontionnalité 2
Fontionnalité 3 Mini-Agile (vrai)
conduit séparément pour Fontionnalité 4
chaque fonctionnalité. Fontionnalité 5

Itération 1 Itération 2 Itération 3 Itération 4 Itération 5 Itération 6

Incrément Incrément Incrément Incrément Incrément Incrément

(produit) (produit) (produit) (produit) (produit) (produit)

Il existe de nombreux cadres de travail utilisant ce cycle de vie adaptatif; tous connus sous le
nom de cadres de travail Agile. Scrum est le cadre de travail Agile le plus connu, bien qu'il
existe d'autres cadres de travail Agile tels que XP, DSDM Atern et Crystal. La seconde moitié
de ce livre est principalement axée sur Scrum, tandis que la première partie sur le concept
d’Agilité est applicable à tous les cadres de travail Agile.

Manifeste Agile
Jusqu'à présent, vous savez qu'un cadre de travail Agile est celui qui utilise un cycle de vie de
développement adaptatif au lieu d'un cycle prédictif. L'agilité a débuté dans les années 50, où elle était
considérée comme un point de vue étrange et parfois anarchiste; à une époque où la méthode
traditionnelle n'avait même pas de nom tel que Cascade, car c'était la manière de facto de travailler.

Le terme «Agile» s’est de plus en plus imposé et formalisé par un groupe qui a préparé et signé une
déclaration de valeurs pour les projets Agile en 2001, connue sous le nom de
Manifeste Agile:

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les
autres à le faire. Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions Plus que Les processus et les outils
Des logiciels opérationnels Plus qu’ Une documentation exhaustive
La collaboration avec les clients Plus que La négociation contractuelle
L’adaptation au changement Plus que Le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Kent Beck Ward Cunningham Andrew Hunt Robert C. Martin
Mike Beedle Martin Fowler Ron Jeffries Steve Mellor Dave Thomas

Page 10
EXIN Agile Scrum
Manuel de Base

Arie van Bennekum James Grenning Jon Kern Ken Schwaber

Alistair Cockburn Jim Highsmith Brian Marick Jeff Sutherland

Page 11
EXIN Agile Scrum
Manuel de Base
© 2001, les auteurs ci-dessus. Cette déclaration peut être copiée sous n’importe qu’elle forme, mais uniquement dans son
intégralité à travers cette notification.

Ce court manifeste explique toute l'idée Agile de la manière la plus simple. Prenez le temps et voyez
comment vous pouvez l'associer à l'idée de cycles de vie adaptatifs.

Valeur 1: les individus et leurs interactions plus que les processus et les outils

La plupart des systèmes de management sont axés sur les processus et les
outils. Nous avons essayé de nous améliorer sans accorder suffisamment
d'attention à la partie humaine des projets. Dans les cas extrêmes, certains
managers considèrent les membres de l'équipe comme de simples pièces
d'une machine complexe, qui peut être facilement remplacée, sans
interrompre le travail. Cependant, nous avons réalisé que nous ne pouvons pas
avoir une machine aussi parfaite dans les projets, à cause de toutes les
incertitudes impliquées et de la créativité requise. Par conséquent, se
concentrer sur les processus et les outils ne suffit pas. La meilleure façon
d'améliorer les performances est de se concentrer sur les aspects humains.

Valeur 2: Des logiciels opérationnels plus qu’une documentation exhaustive

Pourquoi créons-nous une documentation complète en amont? Nous faisons

cela afin de communiquer avec le client et de créer une base pour la solution qui
est censée satisfaire le client. Cependant, le fait est que les clients ne savent pas
ce qu'ils veulent, jusqu’à ce qu'ils voient le logiciel opérationnel, et aucune
documentation ne peut remplacer le logiciel opérationnel à cet effet.
Cela ne signifie pas que nous n'avons aucune documentation dans les projets
Agile, comme certains le croient à tort. Par exemple, nous avons toujours besoin
de manuels d'utilisation, qui peuvent être des documents, même si nous
préférons peut-être les avoir sous forme de vidéos. Nous avons également de
nombreuses informations de suivi dans notre système de gestion de
configuration pour nous aider à soutenir le processus de développement.
Cependant, des documents tels que «spécification des exigences» et
«architecture de solution» ne sont pas utilisés dans un environnement Agile.

Valeur 3: La collaboration avec les clients plus que la négociation contractuelle

Un environnement adaptatif n'a pas de sens sans adaptation, et la base de

l'adaptation est la collaboration du client. Nous ne dépendons d'aucune
conception en amont et nous sommes ouverts à toute modification demandée
par le client à tout moment au cours du projet. Les changements tardifs ne
créent pas beaucoup de retouches pour nous, car nous n'avons pas de
conception en amont à réviser pour chaque changement.

Valeur 4: L’adaptation au changement plus que le suivi d’un plan

Nous ne planifions pas tout le projet à l'avance, car nous savons que nos clients
ne savent pas ce qu'ils veulent. Au lieu de suivre un plan forcé, nous utilisons un
cycle de vie adaptatif, basé sur l’adaptation au changement.

Page 12
EXIN Agile Scrum
Manuel de Base

Principes Agiles
Il y a douze principes accompagnant le Manifeste Agile, qui décrivent encore plus le concept
Agilité:

Principe 1: Notre plus haute priorité est de satisfaire le client en livrant rapidement et
régulièrement des fonctionnalités à grande valeur ajoutée.

Le but est d'avoir un client satisfait, car il reviendra et il nous recommandera

également à d'autres clients potentiels. Mais comment? En leur apportant la
solution qu'ils veulent vraiment et nous savons que ce n'est pas tout à fait
possible sans être adaptatif et fournir un logiciel opérationnel de façon
fréquente, continue et le plus tôt possible. Une telle flexibilité est encore
possible dans les cycles de vie prédictifs, mais elle est trop coûteuse.

Principe 2: Accueillez positivement les changements de besoins, même tard dans le

projet. Les processus Agiles exploitent le changement pour donner un
avantage compétitif au client.
En utilisant un cycle de vie adaptatif, nous pouvons toujours accepter les
changements, car il n'y a pas de grande conception en amont à corriger
chaque fois que nous voulons changer quelque chose.
De plus, nous sommes heureux de recevoir des demandes de changement,
car chaque changement est un pas de plus vers ce que le client veut
vraiment.

Principe 3: Livrez fréquemment un logiciel opérationnel avec des cycles de quelques

semaines à quelques mois et une préférence pour les plus courts.

Le client comprendra mieux ce qu'il veut lorsqu'il verra le logiciel

opérationnel. Nous recevrons des commentaires et les utiliserons pour
l'adaptation. Différents cadres de travail ont des itérations différentes. Dans
Scrum, par exemple, nous ne sommes pas autorisés à avoir des itérations de
plus d'un mois, alors que certains autres cadres de travail acceptent des
itérations plus longues. Nous préférons toujours des itérations plus courtes,
du moment que cela suffit pour créer un incrément significatif (logiciel
opérationnel).

Principe 4: Les utilisateurs ou leurs représentants et les développeurs doivent

travailler ensemble quotidiennement tout au long du projet.

L'implication de l'entreprise / du client se limite généralement à la

spécification des exigences au début d'un environnement prédictif, et à
nouveau à la fin, à l'approbation de la solution finale. Cependant, nous avons
besoin d'eux pour collaborer avec les développeurs au quotidien dans un
environnement adaptatif, car leur apport est à l'origine de l'adaptation.

Page 13
EXIN Agile Scrum
Manuel de Base

Principe 5: Réalisez les projets avec des personnes motivées. Fournissez-leur

l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour
atteindre les objectifs fixés.

Un environnement Agile est basé sur une équipe pluridisciplinaire et auto-

organisée qui se gère elle-même et trouve son chemin au lieu de recevoir des
ordres. C'est une grande responsabilité pour les développeurs et tous les
développeurs ne sont pas capables de travailler de cette manière. Lorsque
nous avons des membres d'équipe appropriés, nous devons leur faire
confiance, les motiver et leur donner les moyens de permettre l'Agilité.

Principe 6: La méthode la plus simple et la plus efficace pour transmettre de

l’information à l’équipe de développement et à l’intérieur de celle-ci est
le dialogue en face à face.

Les membres de l'équipe dans un environnement traditionnel se concentrent

sur leurs activités spécialisées et peuvent même être situés à différents
endroits (généralement dans leurs départements organisationnels). Nous ne
pouvons même pas parfois les appeler une équipe; ce ne sont que quelques
individus travaillant sur le même projet. En revanche, dans un environnement
Agile, nous avons besoin d'une vraie équipe, et les membres devraient
idéalement être colocalisés pour permettre une communication continue.
Après tout, rien ne peut remplacer les conversations en face à face. C'est un
gros avantage d'avoir des équipes colocalisées, mais cela ne signifie pas que
nous ne pouvons pas avoir un projet Agile avec une équipe dispersée.
Cependant, nous devons tirer le meilleur parti de la technologie moderne
pour minimiser tout manque de communication en face-à-face et nous
attendre à un niveau de productivité plus faible en fin de compte.

Principe 7: Un logiciel opérationnel est la principale mesure d’avancement.

Un élément dont les travaux sont effectués à 99% reste à 0% ‘’terminé’’.

Comment pouvons-nous connaître l'avancement d'un lot de travaux, à moins
que nous n'approfondissions les questions techniques? Nous ne le faisons pas,
car nous voulons avoir un langage commun avec les clients qui ne sont pas
forcément techniciens et les garder engagés. La solution à cela est que nous
n'avons que des éléments «terminés» ou «non terminés» dans le backlog² (les
éléments du backlog doivent être non techniques).Et c'est OK; après tout, les
éléments du backlog sont suffisamment petits pour montrer nos progrès par
une simple mesure de terminé / non terminé.

2
Backlog: une liste de fonctionnalités que nous allons développer. Un backlog est comme un plan pour le périmètre du projet.

Page 14
EXIN Agile Scrum
Manuel de Base

Le travail n'est pas le but. Réaliser le produit est le but. Faire des heures
supplémentaires peut sembler accélérer les choses, alors qu'en réalité, cela
réduit la donnée de sortie en diminuant la productivité et en augmentant
les défauts. Nous préférons avoir un rythme soutenable.

Principe 9: Une attention continue à l’excellence technique et à une bonne conception renforce l’agilité.

Éviter la conception en amont ne signifie pas que vous n'avez pas à vous
soucier de la conception. Les projets Agile ont une conception; elle est
juste faite à l'intérieur de chaque itération pour chaque élément du
backlog. Nous devons toujours prêter attention à l'excellence technique et
à une bonne conception pour éviter les problèmes; sans oublier que
l'objectif est une solution «assez bonne» plutôt qu'une solution parfaite.

Principe 10: La simplicité - c’est-à-dire l’art de minimiser la quantité de travail inutile - est essentielle.

Un projet Agile est géré et livré de manière simple. Le management du

périmètre, par exemple, est géré simplement en mettant les informations
essentielles sur une fiche ou un pense-bête. Nous n'avons pas besoin d'outils
sophistiqués pour gérer le projet et le fait de rester simple facilite la
collaboration avec le client.

Principe 11: Les meilleures architectures, spécifications et conceptions émergent d’équipes

auto-organisées.

Les gens travaillent généralement mieux lorsqu'ils sont respectés et ont le

pouvoir de décider comment ils travaillent. Il est préférable que tous les
membres de l'équipe soient responsables de tout dans le projet. Par
exemple, les concepteurs ne travaillent pas seuls;
ils sont en contact permanent avec les programmeurs et peuvent utiliser ces
informations pour améliorer les conceptions et les rendre plus pratiques.

Principe 12: À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace,
puis règle et modifie son comportement en conséquence.

Nous pensons qu'il y a toujours place à l'amélioration, quelle que soit la

qualité de notre travail. Nous passons donc du temps à étudier l'itération
précédente et à trouver des opportunités pour de petites améliorations. Le
but est d'améliorer au moins un peu chaque itération.

Quand Pouvons Nous Utiliser Agile?

Malheureusement, les cadres de travail Agile ne sont pas applicables dans tous les projets.
Ils sont connus pour être applicables dans les projets informatiques, ce qui est correct, mais
ils sont également très utiles dans les initiatives de changement organisationnel et les
projets de recherche.

Alors, est-il possible d'utiliser un cadre de travail Agile pour construire une maison? La réponse est
généralement non. Quelle est selon vous la différence entre ces deux projets?

Page 15
EXIN Agile Scrum
Manuel de Base

Vous vous souvenez de la section précédente que d'avoir un cycle de vie incrémentiel et
itératif est la caractéristique commune des cadres de travail Agile. Le fait est qu'il n'est pas
possible de tout développer comme ça. Dans le cas d'une maison par exemple:

1. Nous ne pouvons pas produire (développer) la maison de manière itérative, car les
résultats intermédiaires ne sont pas des solutions opérationnelles (le client ne peut
pas vivre dans une maison qui est faite à 50%). À quoi sert une fondation de
bâtiment sans les autres parties de la maison? Il n'est pas possible d'arrêter ce
projet au milieu et de commencer à utiliser le produit. À quoi sert une maison sans
ses utilitaires? De plus, tous les processus de développement doivent être exécutés
séparément à l'intérieur des itérations contrairement à une conception initiale
complète, ce qui signifie que nous devrions être en mesure de concevoir la
fondation sans connaître la conception des autres parties de la structure qu'elle va
supporter, ce qui n'est pas possible lors de la construction d'une maison.
2. Nous ne pouvons pas le développer progressivement. Par exemple, nous ne
pouvons pas construire une simple fondation d’un bâtiment et nous permettre de
travailler sur le reste de la structure puis revenir en arrière et l'améliorer avant la
fin du projet.

En outre, pourquoi avons-nous besoin d'un cycle de vie adaptatif lors de la construction
d'une maison? Le client d'une maison sait ce qu'il veut et nous n'avons pas besoin de lui
montrer des solutions intermédiaires pour recevoir un retour d'expérience et adapter en
permanence la structure de la maison.

En tant qu'exercice, considérez l'écriture de ce livre comme un projet. Cela peut-il être fait
de manière itérative et incrémentielle? Si votre réponse est oui, avons-nous «besoin» de le
créer de manière adaptative?

Un autre point qui mérite d'être mentionné ici est la différence entre les projets et les
programmes. Un projet est utilisé pour créer un produit (output), telle qu'un logiciel. Un
programme est utilisé pour créer un résultat (outcome), comme une capacité commerciale,
et est réalisé à travers un certain nombre de projets connexes ou d'autres travaux. Un
projet peut être réalisé de manière prédictive (traditionnelle) ou adaptative (Agile), mais un
programme doit toujours être adaptatif. Il en est ainsi, car un programme est axé sur un
résultat plutôt que sur un produit. Nous pourrons peut-être définir le produit à l'avance,
mais ce n'est pas possible pour les résultats. Nous aurons le résultat à l'esprit et essayerons
de trouver les moyens de l'atteindre, et nous devrions être ouverts à changer les moyens à
mesure que nous progressons.

Donc, s'il s'agit d'un programme, vous devez le livrer de manière adaptative. S'il s'agit d'un
projet informatique, de changement organisationnel, de recherche ou similaire, vous
pouvez utiliser des cadres de travail Agile; mais vous n'êtes pas obligé! Il existe de
nombreux projets informatiques développés dans des environnements traditionnels qui
réussissent. Le fait est que si vous pouvez gérer le changement dans votre organisation et
que vous avez le potentiel requis, vous aurez alors une chance beaucoup plus élevée de
réussir en utilisant les cadres de travail Agile. Plus vous avez d'incertitude et de
changement dans un projet, plus les cadres de travail Agile seront utiles.

Page 16
EXIN Agile Scrum
Manuel de Base

Management du périmètre

Types d’éléments du périmètre

Nous définissons généralement la portée dans un document ou un concept simple ou
structuré. Ce concept est généralement appelé Product Backlog dans les projets Agile. Un
Product Backlog contient un certain nombre d '«éléments», et chaque élément décrit un
élément constitutif de la solution finale.

Nous avons trois alternatives pour définir les éléments du Product Backlog:
1. Spécification des exigences – c'est la manière la plus traditionnelle de définir le
périmètre. Il est formé de termes techniques qui sont clairs pour l'équipe de
développement et sont généralement basés sur les relations architecturales entre
les éléments.
2. Use case – il repose sur la compréhension et les besoins de l'utilisateur plutôt que
sur une description technique, et décrit un scénario détaillé avec toutes les actions
qu'un utilisateur imaginaire fera et les comportements attendus de la solution.
3. User story – ceci est similaire au user case, mais ne contient pas tous les détails du
comportement de l'utilisateur et se concentre uniquement sur les besoins et
l'objectif de l'utilisateur.
Nous devons être capables de communiquer et de collaborer avec le client dans des
environnements Agile afin de recevoir des commentaires et de nous adapter en
conséquence. Après tout, un cycle de vie adaptatif n'est pas utile quand on ne s'adapte pas!
Par conséquent, nous devons avoir un langage commun avec le client. Une définition
technique d'une fonctionnalité n'est pas utile, nous préférons donc utiliser la manière non
technique de définir le périmètre, à savoir les use cases et les user stories. Entre ces deux,
les user stories sont préférées, car elles sont plus faciles à comprendre. Voici un exemple de
user story: En tant qu'utilisateur final, je veux recevoir une liste de mes dernières
transactions. Ou, en tant qu'administrateur système, je veux réinitialiser les mots de passe.
Tout le monde peut les comprendre.
Une user story comprend trois parties:

En tant que …, Je veux …, [pour que …]

1. «En tant que…», définit le rôle qui va interagir dans la story; par exemple, utilisateur final,
administrateur ou manager.
2. «Je veux…», définit l'attente du rôle; par exemple, rechercher des appartements, calculer la taxe,
accorder la permission à quelqu'un et s’inscrire sur le site Web. Veuillez noter qu'il ne s'agit que
d'actions et qu'une phrase comme «en tant qu'administrateur, je veux que mon système utilise
SQL Server» n'est pas une user story! Une user story consiste à faire quelque chose plutôt qu'à
avoir quelque chose.
3. «pour que…», cette partie facultative de la user story explique la raison de cette action et aide à
l'interprétation de la story. La raison de certaines stories est si évidente que vous n'aurez peut-être
pas besoin de la mentionner.

Page 17
EXIN Agile Scrum
Manuel de Base

Il existe deux règles essentielles concernant les éléments du Product Backlog:

1. Ils doivent être non techniques. En effet, le Product Backlog est notre outil de
communication avec le client non technique. Normalement, un enfant de dix ans
devrait être capable de comprendre chaque user story.
2. Ils doivent être indépendants les uns des autres, afin que nous puissions les
développer librement dans n’importe quel ordre.

Nous notons généralement les éléments du Product Backlog sur des fiches ou des post-it et
les plaçons sur un tableau physique. Cette approche est préférable à l'utilisation d'une
application, sauf si vous avez des équipes dispersées.

Adaptation du périmètre
La principale différence avec le management du périmètre Agile est que le périmètre
complet d'un projet traditionnel est défini et convenu à l'avance, avant de commencer la
conception et la construction. Dans les projets Agile, seule une partie du pèrimètre est
définie au départ (autant que nécessaire pour les premières itérations) et nous
commençons à concevoir et à construire la solution avec un périmètre incomplet. Pendant
que nous sommes impliqués dans l'itération, nous ajoutons continuellement de nouveaux
éléments au Product Backlog et affinons ceux existants en fonction des commentaires que
nous recevons du client et de la meilleure compréhension que nous tirons tous du projet.
C'est l'une des principales caractéristiques d'un cycle de vie adaptatif.

Le Product Backlog est un concept dynamique de stockage des éléments que nous allons
développer. Alors,

• Lorsque nous avons terminé avec un article, nous le retirons du Product Backlog;
• Lorsque nous sélectionnons un certain nombre d'éléments du Product Backlog à
développer dans la prochaine itération, nous les sortons du Product Backlog et
les plaçons dans le Backlog d'itération (le Sprint Backlog en cas d'utilisation de
Scrum);
• Si un élément n'est pas terminé avant la fin de l'itération, nous le remettons dans
le Product Backlog; même si il est en cours.

Nous attribuons généralement une valeur commerciale à chaque élément du Product

Backlog et trions la liste, de sorte que les éléments ayant plus de valeur commerciale soient
placés plus haut. Lorsque nous voulons démarrer une nouvelle itération, nous devons
choisir les éléments en haut du Product Backlog, ce qui signifie que nous développons
toujours les éléments qui ont la plus grande valeur commerciale. C'est ainsi que nous
restons concentrés sur la valeur et les besoins de l'entreprise. Certains cadres de travail
Agile utilisent des méthodes telles que la priorisation MoSCoW à la place ou en combinaison
avec les attributions de valeur commerciale quantifiée pour trier les éléments du Backlog.
Nous discuterons de la priorisation MoSCoW plus loin dans ce chapitre.

Le Product Backlog est le principal outil de planification dans la plupart des cadres de travail
Agile. Il contient la portée du projet, ainsi qu'un plan de temps, de ressources, de risques et
de qualité, de la manière la plus simple possible.

Page 18
EXIN Agile Scrum
Manuel de Base

Caractéristiques fonctionnelles et non fonctionnelles

Chaque élément du Product Backlog explique une fonctionnalité (NdT: caractéristique) de la
solution finale, de préférence sous la forme d'une user story. Un problème déroutant est de
savoir comment gérer les caractéristiques non fonctionnelles, car elles sont de nature
technique; Les user stories doivent être non techniques.
Nos exemples précédents de user stories sont tous des caractéristiques fonctionnelles.
D'autres caractéristiques telles que les performances et la sécurité sont des exemples de
caractéristiques non fonctionnelles.
Les caractéristiques non fonctionnelles sont celles qui devraient être appliquées à presque
toutes les caractéristiques fonctionnelles. Prenons l'exemple des performances: il existe des
considérations de performances pour chaque fonctionnalité. Par exemple, nous ne nous
attendons pas à ce qu'une simple recherche prenne deux minutes. La solution consiste à
ajouter les caractéristiques non fonctionnelles dans la Definition of Done (DoD). La
Definition of Done est un concept qui contient toutes les choses que nous devons faire ou
considérer pour chaque user story. Les processus de développement, les critères de qualité,
les normes de codage et les caractéristiques non fonctionnelles font toutes partie de la
Definition of Done.
Ainsi, lorsque nous développons une user story, nous les vérifierions par rapport aux
caractéristiques non fonctionnelles mentionnées dans la Definition of Done, et nous ne les
qualifierions pas de «Done», à moins qu'elles ne les respectent toutes. C'est ce que nous
appelons habituellement les critères d'acceptation dans les environnements traditionnels et
cela fait partie de la planification de la qualité.
Certaines caractéristiques non fonctionnelles pourraient ne s'appliquer qu'à quelques user
stories et par conséquent, la Definition of Done ne serait pas un endroit approprié pour
elles. Dans ce cas, nous les ajoutons simplement au dos de la carte de user story. Oui, nous
pourrions avoir des informations supplémentaires sur certaines user stories, telles que des
critères d'acceptation spéciaux, des descriptions, des caractéristiques non fonctionnelles
spécifiques, etc. Le recto de la carte appartient au texte de la user story (par exemple en
tant qu'administrateur, je veux réinitialiser les mots de passe), la valeur commerciale et
l'estimation (story points). Le dos de la carte appartient à tout le reste. Par exemple,
comment informer l'utilisateur du mot de passe modifié, quels types de mots de passe
acceptons-nous, etc. Et oui, il doit être court; Nous n’avons pas autant d'espace au dos de la
carte, et c'est tout l'intérêt: nous devrions maintenir la chose simple.↑
ID: 0209 Valeur: 2842 • Seuls les mots de passe forts sont acceptables.
• Le lien de réinitialisation du mot de passe doit
En tant qu’utilisateur final, je veux être envoyé à l’adresse Email enregistrée.
réinitialiser mon mot de passe, pour • L’utilisateur doit répondre correctement à la
que je puisse accéder de nouveau à question de sécurité avant de pouvoir
mon compte. Estimation: 5 SP réinitialiser le mot de passe.

Recto d’un exemplaire d’élément du Backlog Verso d’un exemplaire d’élément du Backlog

Alors, il ne faut pas oublier ceci : chaque user story doit être compréhensible et démontrable
au client non technique. Il faut éviter le jargon, à moins d’être en train de parler avec l’équipe
de développement.

Page 19
EXIN Agile Scrum
Manuel de Base

Les Bugs
Nous créons un incrément opérationnel de la solution finale à la fin de chaque itération, qui
devrait être potentiellement livrable. Nous les gardons «potentiellement livrables», afin
qu'il soit plus facile pour le client de l'essayer et de nous faire part de ses commentaires.
Certaines des itérations peuvent en fait être livrées et utilisées par les utilisateurs finaux.
Il est très courant de découvrir des bugs après la démonstration de l'incrément
potentiellement livrable ou même lors de l'utilisation du produit livré. Dans ce cas, il existe
différentes manières de les gérer:

• Il est préférable de créer des stories pour les bugs et de les ajouter au Product
Backlog. Nous n'ajoutons jamais de nouveaux éléments au backlog d'itération
actuel, car nous devons nous concentrer sur les éléments présélectionnés. Donc,
dans ce cas, nous devons attendre la prochaine itération pour sélectionner le bug
dans le Product Backlog et l'ajouter au Backlog de la prochaine itération à corriger.
Bien sûr, les bugs doivent être triés comme les autres user stories, et s'ils n’ont pas
une valeur élevée, nous devrons attendre une itération ultérieure avant de les
corriger.
• S'il n'est pas acceptable d'attendre trop longtemps pour corriger les bugs (si le
produit est utilisé à ce moment-là), nous pouvons les garder en dehors du Product
Backlog et attribuer un effort maximum prédéfini de l'équipe (5%, par exemple)
pour travailler sur les bugs au lieu de développer de nouveaux articles. Nous
utilisons généralement un Backlog séparé et un tableau Kanban3 pour la gestion
des bugs dans ce cas.

Il est inévitable que nous ayons des bugs; mais combien? Si vous avez beaucoup de bugs,
vous devriez peut-être améliorer votre Definition of Done en ajoutant plus de tests, en
améliorant la façon dont vous développez, etc. Il est vraiment important d'être proactif.
Si un défaut n'est pas détecté par l'équipe de développement et est trouvé par les
utilisateurs finaux après une livraison, il s'agit d'un escaped defect. Le nombre de escaped
defect est une métrique importante pour mesurer la qualité du travail.

Les Spikes
Parfois, nous ne savons pas comment développer quelque chose d'un point de vue
technique. Dans ce cas, nous utilisons un «spike» pour l'étudier; une petite activité de
développement pour apprendre les éléments techniques de la solution.

Il existe deux types de spikes:

1. Spikes techniques: ils visent à trouver l'approche de développement;

2. Spikes fonctionnels: il s'agit davantage de prototyper et de trouver ou de
comprendre les fonctionnalités requises.

3
tableau Kanban: un tableau montrant les différentes étapes des travaux, utilisé pour suivre l’état de chaque
élément de travail. Les éléments sont généralement ajoutés au tableau à l’aide des post - it.

Page 20
EXIN Agile Scrum
Manuel de Base

Les spikes doivent être timeboxés (par exemple : un ou deux jours). Certaines équipes
réalisent les spikes en dehors des itérations normales, tandis que manière plus courante
d’autres les réalisent dans les itérations de développement.
Un spike fait parfois référence à une tâche comprise dans de multiples tâches requises
pour un élément du Product Backlog. Ce sont généralement des éléments séparés. Par
exemple, nous pouvons avoir un spike pour une user story normale dans l'itération
actuelle, et la story réelle dans l'itération suivante.
L'une des principales raisons de réaliser des spikes est de permettre à l'équipe de donner
une estimation de la user story. Ce n'est pas une exploration complète, mais plutôt une
étude brève et rapide, visant à comprendre et à estimer.

Priorisation MoSCoW
La Priorisation MoSCoW est une excellente technique pour le management du périmètre
et constitue une partie essentielle de DSDM Atern. Il n'est pas encore très courant de
l'utiliser dans les cadres de travail Scrum, mais c'est une bonne idée de l'utiliser quand
même.
MoSCoW est une combinaison des premières lettres de Must Have, Should Have, Could
Have, et would not Have This Time. Dans cette technique, nous attribuons une de ces
lettres à chaque fonctionnalité, en fonction de la définition suivante:

• M (Must Have) – est une fonctionnalité qui doit être dans le produit final, et le
produit final serait inutile sans elle. Par exemple : les freins dans une voiture.
• S (Should Have) – est une fonctionnalité très importante pour le produit final, et
nous ferons face à des problèmes sans elle. Cependant, nous pouvons trouver une
solution de contournement pour cela (en utilisant une autre solution en parallèle,
en le faisant manuellement, etc.) et tout en utilisant toujours la solution finale qui
manque cette fonctionnalité. Par exemple: la climatisation dans la voiture.
• C (Could Have) – est une fonctionnalité vraiment utile que nous aimerions vraiment
avoir dans notre solution, mais franchement, cela ne créerait pas de problème si
nous ne l'avons pas. Par exemple : une caméra et avec un écran dans la voiture, qui
peuvent nous aider à faire la marche arrière.
• W (Will not Have This Time) – est une fonctionnalité intéressante, mais nous
n'allons pas y investir maintenant. Peut-être plus tard. Par exemple : la
surveillance en ligne de l'état mécanique de la voiture.

Lorsque nous attribuons ces priorités de manière réaliste, nous savons que le minimum
pour un produit acceptable est la solution contenant toutes les M user stories. Notre
produit attendu est celui qui contient toutes les user stories M et S. Le produit idéal est
celui qui contient toutes les user stories M, S et C.
La priorisation MoSCoW est un excellent moyen de se concentrer sur la valeur
commerciale: se concentrer sur les besoins réels au lieu des fonctionnalités fantaisistes
(Could Have items).

Page 21
EXIN Agile Scrum
Manuel de Base

Garder le périmètre dynamique

Le périmètre d'un projet est fixe dans les méthodes traditionnelles. Nous avons un
ensemble d'exigences précisément défini, et nous essayons de les réaliser dans un budget,
un temps et une qualité prédéfinis. Cependant, nous ne sommes pas toujours en bonne
voie; dans ce cas, nous ne voulons pas compromettre le périmètre, mais plutôt augmenter
le temps ou le budget ou diminuer la qualité afin de fournir toutes les fonctionnalités. Ceci
n'est pas favorable dans les cadres de travail Agile.
Nous nous concentrons sur les besoins de l'entreprise dans les cadres de travail Agile, et le
fait de compromettre le temps ainsi que la qualité n'est pas une bonne idée, car les produits
informatiques ont une durée de vie opérationnelle très courte. Si nous passons plus de
temps à créer une solution juste pour inclure toutes les fonctionnalités fantaisistes, nous
perdons de la valeur.
Certains cadres de travail Agile n'autorisent pas les changements de durée. Le projet est
garanti d'être terminé à temps. Si quelque chose ne va pas, nous supprimerons plutôt
certaines des fonctionnalités inutiles (périmètre) au lieu de changer la durée. DSDM Atern
est l'un de ces cadres de travail.

La figure suivante montre les triples contraintes classiques des projets et les différentes
manières dont nous pouvons les gérer:

Approche Atern
Fixe
Fonctionnalité Durée Coût

Qualité

Qualité ?

Variable
Durée Coût Fonctionnalité

Approche Traditionnelle

Il n'est pas nécessaire de suivre le principe Atern de livrer à temps dans Scrum.
Cependant, nous développons d'abord des user stories à plus forte valeur ajoutée.
Ainsi, l'augmentation de la valeur de chaque itération sera de moins en moins au fur
et à mesure que nous progressons dans le projet. Nous aidons le client à réaliser cela,
et nous devons donc être prêts à arrêter le projet après chaque itération. Lorsque le
client se rend compte que l'itération actuelle a une valeur suffisante, il peut ne pas
vouloir ou ne pas avoir besoin de dépenser plus de temps et d'argent pour recevoir
les fonctionnalités de faible valeur restantes, il peut donc choisir de clôturer le projet.
C'est une autre raison pour laquelle nous devons garder les itérations
«potentiellement livrables».

Page 22
EXIN Agile Scrum
Manuel de Base

Périmètre du produit dans les environnements Agile

Pour comprendre la différence entre le périmètre du produit final dans un environnement
Agile et la différence qu'il y a avec l’environnement traditionnel, jetez un œil au diagramme
suivant qui montre le résultat d'une recherche réalisée par le groupe Standish en 2011,
concernant l'utilisation moyenne des fonctionnalités d’un logiciel.

Toujours
7%
Souvent
13%

Jamais
45%
Quelque fois
16%

Rarement
19%

L’utilisation moyenne des fonctionnalités

d’un logiciel (2011)

C'est le désastre que nous essayons d'éviter dans les environnements Agile: près de la
moitié des fonctionnalités d'un logiciel moyen ne sont presque jamais utilisées, ce qui
signifie que nous dépensons deux fois plus de temps et d'argent; un vrai gaspillage. La
principale raison pour laquelle les projets Agile sont plus rapides est que nous intégrons un
mécanisme qui élimine ces données de sortie.

La raison de ce gaspillage dans les environnements traditionnels est que nous obligeons le
client à tout spécifier à l'avance, et comme le changement est généralement suivi de
réclamations concernant le délai et le coût plus tard dans le projet, le client essaie de
réfléchir à toutes les fonctionnalités possibles dont il pourrait avoir besoin. Il s'avère que la
plupart de ces fonctionnalités spécifiées à l'avance sont inutiles. Nous n'avons pas ce
problème dans les projets Agile pour deux raisons:

1. Nous ne forçons pas les clients à tout spécifier à l'avance, ils n'ont donc pas besoin
d'être trop créatifs en définissant toutes les fonctionnalités possibles. De plus, ils
savent que nous acceptons les changements à tout moment, afin qu'ils puissent se
détendre
2. Nous aidons le client à comprendre la valeur commerciale de chaque fonctionnalité
et à éviter celles qui n'aident pas vraiment l'entreprise, même si elles ont été
définies dans le Product Backlog.

Page 23
EXIN Agile Scrum
Manuel de Base

Le Concept de Timebox
Il existe un concept important utilisé dans les cadres de travail Agile: timebox.
Chaque timebox a deux caractéristiques majeures:
1. Il a une durée maximale prédéfinie. Nous ne prolongeons jamais la durée de la
timebox simplement parce que nous devons terminer quelque chose. On
s'adapte pour tout finir à l'intérieur de la timebox, et si ce n'est pas possible,
on retire les activités qui ont le moins d'importance. Ainsi, chaque timebox a
un temps maximum, cependant, il existe deux types de timebox concernant le
temps minimum:
a. Durée fixe: certaines des timeboxes sont complètement fixes, et non
seulement le temps maximum n'est pas extensible, mais aussi le minimum
est fixe. Donc, si nous avons tout fait, et qu'il nous reste encore du temps,
soit nous choisissons de nouvelles activités en fonction des règles définies
dans le cadre de travail, soit nous prenons simplement du temps libre! Ce
type de timebox est utilisé pour créer de la régularité et est généralement
utilisé pour les grands événements.
b. Durée maximale: certaines autres timeboxes ont une durée maximale, qui
n'est pas extensible, mais n'a pas de durée minimale. Donc si nous en avons
fini avec toutes les activités et avons du temps supplémentaire, la timbox
sera considérée comme clôturée, et nous commencerons une autre timebox.
Ce type est utilisé pour maximiser la flexibilité, ainsi que la régularité, et est
généralement utilisé pour les petits événements ou ceux qui ne peuvent pas
avoir d'activités supplémentaires.
2. Les timeboxes ont un ensemble d'éléments prédéfinis et généralement figés à
terminer. Nous définissons les éléments à l'avance et ne les modifions pas.
Nous pouvons affiner les éléments (par exemple : les user stories), mais nous
ne les modifions pas complètement. Nous n'ajoutons pas de nouveaux
éléments ni ne supprimons d'éléments. Bien sûr, ce n'est le cas que jusqu'à la
prochaine timebox, lorsque toutes les nouvelles modifications sont
appliquées. Il en est ainsi, car tout change constamment dans les
environnements Agile, et nous devons nous concentrer pour rester productifs.
Ainsi, alors que tout change, nous gardons les courtes durées figées et nous
nous concentrons sur le développement. La seule exception est que si la
timebox est d'une durée fixe au lieu d'une durée maximale, nous pouvons
ajouter des activités supplémentaires une fois que nous en avons terminé
avec toutes celles prédéfinies.
Comme vous l'avez peut-être deviné, chaque itération est timeboxée. Ce sont des
timeboxes à durée fixe dans la plupart des cadres de travail. Nous avons également de
nombreuses réunions à l'intérieur ou à l'extérieur des itérations, qui sont également
timeboxées; par exemple : planning timebox. Vous pouvez voir un exemple concret de
Scrum timeboxing dans les chapitres suivants.
L'utilisation des timeboxes est une excellente stratégie pour augmenter la productivité, à
la fois dans votre vie personnelle et dans vos projets. Certains des avantages sont:

1. Cela crée de la régularité et de la discipline, et en particulier, nous aide à créer

des solutions potentiellement livrables;

Page 24
EXIN Agile Scrum
Manuel de Base

2. Cela aide à accroître la concentration, en particulier là où tout change et où de

nouvelles choses surgissent tout le temps;
3. Cela nous aide à nous concentrer sur la valeur et les besoins de l'entreprise. Étant
donné que la durée maximale est toujours fixée dans les timeboxes, nous ne
pouvons pas prolonger le temps pour terminer quelque chose, et au lieu de cela,
nous devons comprendre les valeurs et abandonner certaines des activités qui ont
moins de valeur.

Planning en forme d’oignon (Planning Onion)

Il existe différents niveaux de planification liés à un projet Agile, qui peuvent être
représentés dans un diagramme en forme d'oignon tel que celui ci-dessous:

Stratégie

Portfeuille

Produit

Livrable
Itération
Jour

Les niveaux de planification de la stratégie et du portefeuille sont en dehors des projets,

gérés par les systèmes de gestion plus larges de l'organisation. La planification stratégique
définit les avantages pour l'organisation (par exemple : gagner de l'argent), et le niveau du
portefeuille sélectionne et obtient les ressources pour les meilleurs projets possibles pour
optimiser les avantages.

À l'intérieur de chaque projet Agile, il existe quatre niveaux conceptuels de planification:

1. Planning du produit (Product planning) – généralement effectuée dans le Product Backlog

et probablement dans certains plans supplémentaires de haut niveau tels que la vision du
produit, en fonction du cadre de travail utilisé.
2. Planning du livrable (Release planning) – ce niveau prévoit le moment où les
incréments doivent être disponibles pour les utilisateurs finaux pour les opérations
réelles. Dans certains cadres de travail comme Scrum, nous n'avons pas ce type de
planning spécifique aux livrables, car nous sommes toujours prêts à livrer le dernier
incrément.
3. Planning de l’itération (Iteration planning) – dans le cas de Scrum, ce niveau de
planification est effectué lors de la Sprint planning meeting et crée le Sprint
Backlog. Il s'agit d'une liste d'éléments (user stories) sélectionnés en haut du
Product Backlog à développer au cours de l'itération courante.

Page 25
EXIN Agile Scrum
Manuel de Base

4. Planning du jour (Day planning) – dans Scrum, par exemple, ce niveau se fait en
décomposant le Sprint Backlog des éléments dans les tâches, et il est également
discuté après les Daily Scrums.

Pratiques Agile
Il existe un certain nombre de pratiques courantes dans les environnements Agile qui
aident vraiment à améliorer la progression de votre projet. Certaines des pratiques ne se
limitent pas à l’Agile et vous pouvez également en bénéficier dans les environnements
traditionnels. Certaines pratiques essentielles sont expliquées dans les chapitres
précédents ou seront expliquées dans les chapitres du cadre de travail Scrum. Cette
section présente certaines des autres pratiques courantes.

Programmation en binôme (Pair Programming)

La programmation en binôme consiste à faire travailler deux développeurs sur un même poste de
travail. L'un d'eux s'appelle le pilote, qui écrit le code, et l'autre s'appelle le navigateur, qui observe
et commente. Ces deux personnes changent fréquemment de rôle (toutes les heures, par exemple).

Voici les principaux avantages de la programmation en binôme:

• Travailler est plus agréable pour les gens lorsqu'ils travaillent à deux. Eh bien, il y a parfois
des conflits, mais ils ne sont pas causés par la programmation en binôme; ce sont des
problèmes existants qui se sont manifestés grâce à la pratique de la programmation en
binôme, et sinon, ils se seraient manifestés ailleurs;
• Les gens apprennent davantage lorsqu'ils se regardent travailler;
• Travailler est plus agréable pour les gens lorsqu'ils travaillent à deux. Eh bien, il y a parfois
des conflits, mais ils ne sont pas causés par la programmation en binôme; ce sont des
problèmes existants qui se sont manifestés grâce à la pratique de la programmation en
binôme, et sinon, ils se seraient manifestés ailleurs;
• Les gens apprennent davantage lorsqu'ils se regardent travailler;

Il peut sembler étrange au début de confier à deux personnes le travail d'une seule
personne et cela peut sembler un gaspillage. Cependant, le fait est qu'en pratique, le
rendement d'une paire de programmeurs, y compris tout le debug, est plus que le double
du produit créé par deux programmeurs distincts. Il est donc même économique d'utiliser
cette pratique.

Facteur Bus (Bus Factor)

Vous perdez l'un des membres de votre équipe projet, pour quelque raison que ce soit (par
exemple : un bus le/la cogne et…), et vous n'êtes plus en mesure de continuer le projet, car
personne d'autre n'a les informations clés pour le projet. C'est un projet avec un facteur
bus (Bus factor)de 1, ce qui est terrible.
Le nombre minimum de développeurs que vous devez perdre avant de perdre la capacité
de continuer le projet (même en ajoutant de nouveaux développeurs) est appelé votre
facteur bus (Bus factor) ou facteur camion (Truck factor). Des nombres plus élevés sont
certainement souhaités.

Page 26
EXIN Agile Scrum
Manuel de Base

Un environnement pluridisciplinaire et auto-organisé est une excellente opportunité pour

augmenter le facteur bus et, par conséquent, diminue les risques négatifs. Cependant, vous
pouvez mettre plus de mécanismes en place pour aider à cet aspect par la planification de
la relève (succession planning).
La planification de la relève consiste à conserver les informations à l'intérieur de l'équipe,
au lieu de certaines personnes, et permet de changer de responsabilité, voire d'ajouter ou
de supprimer des développeurs dans des cas extrêmes. La programmation en binôme est
un excellent moyen de planifier la relève et d'augmenter le facteur bus, car tout est bien
connu d'au moins deux personnes au lieu d'une seule.
Maximiser la transparence, améliorer les communications (daily standups, démos,
systèmes de gestion de configuration), et pratiquer une véritable copropriété de code sont
d'autres moyens d'augmenter le facteur bus.
Les résultats d'un plan de relève réussi ne se limitent pas aux cas extrêmes de perte de
personnes. Il est également très utile pour le déroulement naturel du projet, car les
membres de l'équipe peuvent tomber malades, partir en vacances ou simplement être
distraits de temps en temps. Ces problèmes peuvent entraîner de graves problèmes dans
un environnement à faible facteur bus.

Developpement piloté par les tests (Test-Driven Development)

Le développement piloté par les tests est la pratique dans laquelle des scénarios de test
sont préparés avant l'écriture du programme. Ainsi, le but du programmeur est d'écrire
quelque chose qui puisse passer le test exact.
Voici quelques-uns des avantages du développement piloté par les tests:

• Les programmeurs savent exactement ce que les autres attendent d’eux et peuvent
travailler de manière plus productive;
• Les programmeurs seront encouragés à créer le programme le plus simple
possible, juste pour réussir le test. Ceci est souhaitable dans les environnements
Agile, car nous ne voulons pas perdre de temps à créer quelque chose de parfait,
alors que tout ce dont nous avons besoin est d'une solution suffisamment bonne
pour faire le travail. Cependant, nous devons généralement surveiller la
refactorisation pour nous assurer que la solution est toujours «assez bonne».

Intégration Continue
Les morceaux de code sont généralement intégrés à la fin du projet ou de la phase dans un
environnement traditionnel, alors que nous préférons avoir une intégration continue dans
des environnements Agile. Tous les programmeurs doivent télécharger leurs dernières
versions de code dans le référentiel de solution toutes les heures environ.

Cette pratique nous permet d'être sûrs que nos travaux antérieurs sont «terminés» et ne
nécessitent pas trop d'ajustements supplémentaires. Cependant, il est nécessaire d'avoir
un système de gestion de configuration fiable pour permettre cette pratique sans
rencontrer de problèmes, en particulier lorsque la donnée de sortie est utilisée dans les
opérations.

Certains avantages clés de la pratique d'intégration continue sont:

• Il est plus facile d'avoir des incréments réels à la fin des itérations; livrer la solution serait beaucoup
plus facile que dans les environnements traditionnels;
Page 27
EXIN Agile Scrum
Manuel de Base

• Nous voyons des alertes précoces pour les conflits et moins de retravail dans le futur code.

L'intégration continue est généralement utilisée en combinaison avec des environnements

de test automatisés.

Refactorisation Continue
Le refactorisation est l'amélioration du code sans changer ses fonctions externes. La
refactorisation continue consacre une partie du temps de développement à la
refactorisation pour faciliter le développement futur et la maintenabilité.
Les principaux avantages de la refactorisation continue sont:

• Le développement des parties restantes du projet est plus rapide et plus fluide;
• Nous pouvons accumuler de nombreuses leçons apprises à intégrer dans les
parties restantes du projet et dans les projets futurs.

Il faut veiller à ne pas cibler le code parfait au lieu d'un code assez bon. Une refactorisation
continue minimale est requise dans les environnements Agile, car nous ne développons
pas sur la base d'une conception en amont.
La refactorisation continue est la stratégie Agile de remboursement de la dette technique.
La dette technique est la conséquence éventuelle d'un développement médiocre, qui
devrait être remboursée à un moment donné, et le plus tôt sera le mieux.

Propriété Collective du Code

Personne dans l'équipe Agile n’est propriétaire d’un fragment de code; tout le monde est
responsable de tout, et chacun est autorisé à modifier n'importe quel fragment de code.
Les principaux avantages de la propriété collective du code sont:

• Encourager la collaboration;
• Faire en sorte que chacun se concentre sur le projet et sa valeur plutôt que sur des
activités de spécialiste.

Cette pratique est obligatoire dans la plupart des cadres de travail Agile, y compris Scrum.

Rythme soutenable
Avoir un rythme soutenable, comme vous vous en souvenez peut-être d'après les principes
Agile, est nécessaire. Avoir des heures supplémentaires constantes peut sembler augmenter
la vitesse, mais dans la pratique, cela ralentit en fait tout à cause de la faible qualité du code
et du moral de l'équipe.

Les principaux avantages d'avoir un rythme soutenable sont:

• Les développeurs sont plus concentrés sur la production que sur le travail; ils se
concentrent sur le projet dans son ensemble plutôt que sur les activités;
• Nous aurons un environnement plus heureux;
• En fin de compte, nous aurons une productivité plus élevée.

L'utilisation d'unités relatives (story points) pour mesurer l'effort de chaque élément du
Product Backlog au lieu d'unités basées sur le temps nous aide à maintenir le rythme
soutenable.

Page 28
EXIN Agile Scrum
Manuel de Base

2
Cadre de travail
Scrum

Page 29
EXIN Agile Scrum
Manuel de Base

Cadre de travail Scrum

Vous avez maintenant une compréhension abstraite de l'Agilité, et vous vous êtes peut-être
demandé comment il est possible de la faire fonctionner. Eh bien, Scrum est l'une des
réponses à une telle question; l'une des meilleures réponses en fait. La plupart des
entreprises Agile utilisent Scrum de nos jours:

Autres
34%

Scrum
52%

Scrum+XP
14%

Scrum n'appartient pas à une certaine organisation, comme le sont PRINCE2 et PMBOK
Guide, il existe donc différentes interprétations de celui-ci disponibles dans diverses
ressources. La ressource la plus créditée parmi toutes est scrum.org, définie dans un guide
très court appelé Scrum Guide. Ce guide est une très bonne référence, mais ce n'est pas un
matériel didactique d'auto-apprentissage. Nous avons gardé cette partie du livre
compatible avec Scrum Guide.

Aperçu Rapide du Cadre de travail Scrum

Chaque projet Scrum est réalisé en plusieurs Sprints. «Sprint» est le terme Scrum pour
designer une «itération».Nous utilisons un Product Backlog pour définir le périmètre restant
du produit. Nous sélectionnons un certain nombre d'éléments en haut du Product Backlog à
traiter pendant le Sprint actuel. Nous exécutons des Sprints autant de fois que nécessaire,
jusqu'à ce que:
1. le projet soit terminé, parce que:
a. tous les éléments du Product Backlog sont terminés;
b. le client a réalisé que la dernière itération était suffisante, et rien ne justifie de
consacrer plus de temps et d'argent pour ajouter plus de fonctionnalités;
2. le projet est arrêté pour une raison quelconque (par exemple : il n'est plus justifié).

Page 30
EXIN Agile Scrum
Manuel de Base

La figure suivante montre un aperçu du cadre de travail:

Product
Backlog Product Product
Backlog Product
Backlog Backlog

Sprint Backlog Sprint Backlog Sprint Backlog Sprint Backlog

Sprint #4 Sprint #5 Sprint #6 Sprint #7 Sprint #8

Increment #4
Increment #5 Increment #6 “Done”, and
potentially
Increment #7 releasable

To be applied
to the Product
Feedback Feedback Feedback Feedback
Backlog

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint #6

Voir le «Sprint # 6» comme un exemple: chaque Sprint lui-même a un certain nombre de timeboxes :

• Sprint Planning: une courte timebox pour sélectionner les user stories en haut de la Product
Backlog et créer le Sprint Backlog;
• Daily Scrum: un timebox de 15 minutes pour collaborer et coordonner au quotidien;
• Sprint Review: pour démontrer l’incrément au client et recevoir des commentaires;
• Sprint Retrospective: for pour revoir le Sprint et planifier les améliorations.

Il y a trois rôles dans Scrum:

• Product Owner – cette personne est responsable de la création et de la maintenance du

Product Backlog, ce qui nécessite une communication et une collaboration constantes avec
le client;
• Scrum Master – cette personne s'assure que le cadre de travail Scrum est suivi entièrement et
correctement, ce qui nécessite un coaching, une formation et la résolution de problèmes;
• Development Team – un ensemble d'experts techniques, mais auto-organisés et
pluridisciplinaires qui développent la solution.

Page 31
EXIN Agile Scrum
Manuel de Base

Remarque: les «programmeurs» sont appelés «développeurs» dans certaines entreprises. Dans
la littérature Agile, un «développeur» est toute personne qui contribue à la production de la
solution finale. Le terme «développeur» peut désigner des analystes, des concepteurs de
solutions, des concepteurs d'interface utilisateur, des programmeurs, des testeurs, etc.

Le cadre de travail Scrum sera expliqué dans les trois chapitres suivants:

• Les rôles (Scrum Roles), qui explique les trois rôles plus en détail;
• Les évènements (Scrum Events), qui explique toutes les timeboxes définies dans Scrum,
ainsi que le cycle de vie de développement et de gestion du cadre de travail;
• Les artefacts (Scrum Artifacts), qui explique le management produits / concepts requis
dans Scrum (par exemple, surveillance des performances).

Les rôles (Scrum Roles)

L’équipe Scrum (Scrum Team)

Il y a trois rôles dans un projet Scrum; ni moins ni plus. Nous ne sommes pas autorisés à définir
d'autres rôles, car cela nuit à l'unité de l'équipe et n'est pas compatible avec la philosophie de
Scrum.

Page 32
EXIN Agile Scrum
Manuel de Base

L’équipe Scrum est constituée de ces trois rôles suivants :

Product Owner Scrum Master Development Team

1 peronne 1 peronne 3 à 9 personnes

à plein temps ou à temps partiel à plein temps ou à temps partiel à plein temps (recommandé)
Orienté Business Coach Scrum et facilitateur Spécialistes

Le terme «Scrum Team» fait référence à tous les membres de l'équipe projet: tous ceux qui sont
internes au projet. Les membres de l'équipe Scrum n'ont généralement qu'un des trois rôles
standard de Scrum: Product Owner, Scrum Master ou Development Team. Il est cependant
possible qu'une seule personne soit affectée à plus d'un des rôles standard, mais cela n'est pas
recommandé.
L'équipe Scrum fait partie de l'organisation exécutante (l'entreprise qui exécute le projet soit
pour elle-même, soit en tant que contractant pour un client externe).
D'autres personnes peuvent également être impliquées dans le projet, mais elles ne sont pas
considérées comme internes au projet et la théorie Scrum n'a pas grand-chose à dire à leur sujet.
Ils doivent cependant avoir un certain nombre de comportements pour permettre à un projet
Scrum de réussir.
Le client (qu’il soit interne ou externe) doit également comprendre et adopter le cadre de travail
Scrum, car la relation entre le client et l'équipe Scrum et la façon dont nous livrons le projet
change complètement lorsque nous passons au le cadre de travail Scrum.
L'équipe Scrum a deux caractéristiques essentielles:

• Auto-organisée: l'équipe Scrum gère ses propres efforts plutôt que

d'être gérée ou dirigée par d'autres. Dans les méthodes traditionnelles,
les efforts de management sont séparés et centralisés; un sous-
ensemble de l'équipe de projet est responsable de la gestion de projet,
et d'autres sont uniquement responsables des activités spécialisées.
Cependant, les efforts de management et de spécialistes ne sont pas
séparés dans Scrum.

Page 33
EXIN Agile Scrum
Manuel de Base

• Pluridisciplinaire : l'équipe Scrum possède toute l'expertise et les compétences

nécessaires pour faire le travail sans aucune aide extérieure à l'équipe.

Ces deux caractéristiques sont conçues pour optimiser la flexibilité, la créativité et la productivité
nécessaires à l'environnement Agile de Scrum.

Rôle 1: Le Product Owner

Product Owner Scrum Master Development Team

1 personne 1 personne 3 à 9 personnes

à plein temps ou à temps partiel à plein temps ou à temps partiel à plein temps (recommandé)
Orienté Business Coach Scrum et facilitateur Spécialistes

Chaque projet a besoin d'une personne orientée Business, visant à maximiser la valeur
commerciale du produit et le travail de l'équipe de développement. Dans Scrum, cette
personne est appelée le Product Owner. Les Product Owners, comme les deux autres rôles,
sont issus de l'organisation exécutante plutôt que du côté client. Il peut y avoir une ou
plusieurs personnes du côté client affectées à la gestion du produit, mais elles ne seront
pas appelées Product Owners.
Ce rôle appartient à une seule personne. Il peut y avoir un comité pour assumer les
responsabilités de ce rôle, mais dans un tel cas, il devrait y avoir une personne
représentant ce comité, et nous appelons cette personne le Product Owner.
Ils n'ont pas besoin de connaître le domaine d'application du projet; ils se concentrent sur
les aspects commerciaux. Dans les projets de développement de logiciel, par exemple, les
Product Owners n'ont pas besoin d'être eux-mêmes des développeurs; ils ont juste besoin
d'en savoir un peu plus sur le développement et sur le fonctionnement de l'entreprise.
Le Product Owner est responsable du Product Backlog. Le Product Backlog est une liste
priorisée d'éléments (généralement des user stories) que le client attend du projet; c'est le
principal outil de planification de Scrum. Il est également de la responsabilité du Product
Owner de s'assurer que chaque élément (user story) est facile à comprendre pour l'équipe
Scrum et les autres parties prenantes.

Page 34
EXIN Agile Scrum
Manuel de Base

Les Product Owners doivent communiquer efficacement avec le client (le facteur de succès
inévitable dans chaque méthode de gestion de projet) et utiliser ces informations pour
maintenir le Product Backlog à jour avec tous les changements. Ils mesurent également la
performance du projet, prévoient la date d'achèvement et rendent ces informations
transparentes pour toutes les parties prenantes.

Communications
Exigences

Communications

Client Organisation réalisatrice /

Scrum Team

Les Product Owners comprennent l'entreprise, de sorte qu'ils peuvent classer chaque
élément du Product Backlog en fonction de son retour sur investissement ainsi que de tout
autre facteur qu'ils jugent adapté au point de vue commercial du projet. Les éléments
seront triés en fonction de leur valeur commerciale (ou simplement de la «valeur» en
abrégé), de sorte que plus ils sont élevés dans la liste, plus tôt ils seront développés par
l'équipe de développement.
Toute l’organisation doit respecter les décisions du Product Owner pour que le projet
aboutisse. Personne, pas même le PDG, ne devrait se permettre d'essayer de passer outre
ces décisions. Personne ne doit dire à l'équipe de développement quel article livrer, à
l'exception du Product Owner, qui définit et ordonne les articles. Les décisions d’un
Product Owner peuvent être influencées par d’autres, mais il doit avoir le dernier mot.
Les Product Owners peuvent déléguer certaines de leurs responsabilités (telles que la
préparation de la liste des éléments pour le Product Backlog) à l'équipe de développement,
mais ils en restent responsables.

Page 35
EXIN Agile Scrum
Manuel de Base

Rôle 2: Le Scrum Master

Product Owner Scrum Master Development Team

1 personne 1 personne 3 à 9 personnes

à plein temps ou à temps partiel à plein temps ou à temps partiel à plein temps (recommandé)
Orienté Business Coach Scrum et facilitateur Spécialistes

Les Scrum Masters sont ceux qui comprennent parfaitement Scrum et aident l'équipe
Scrum en les coachant et en s'assurant que tous les processus Scrum sont correctement
mis en œuvre. Le Scrum Master est un poste de management, dans lequel le Scrum Master
gère les processus Scrum, plutôt que l'équipe Scrum. Il / elle est un leader-serviteur de
l'équipe Scrum.
En plus de s'assurer que l'équipe de développement comprend et utilise correctement
Scrum, le Scrum Master essaie également de lever les obstacles à l'équipe de
développement, facilite leurs événements, les forme et les coache.
Les Scrum Masters aident également les Product Owners, en les aidant ou en les coseillant
pour trouver des techniques, communiquer des informations et faciliter des événements
connexes.
Les responsabilités des Scrum Masters ne se limitent pas à l'équipe Scrum. Ils doivent
également aider les personnes extérieures à l'équipe Scrum à comprendre les interactions
appropriées avec l'équipe Scrum afin de maximiser la valeur commerciale. Le Scrum Master
conduit généralement l'organisation dans ses efforts pour adopter Scrum.
Il est possible qu'une seule personne soit à la fois Scrum Master et membre de l'équipe de
développement, bien que cela ne soit pas recommandé. Être Scrum Master d'un projet
normal peut ne pas occuper 100% du temps d'une personne; dans ce cas, la meilleure
solution est d'affecter cette même personne en tant que Scrum Master dans plus d'un
projet, plutôt que d'en faire un membre de l'équipe de développement.
La plupart des communications internes et externes sur le processus Scrum sont effectuées
par le Scrum Master, alors que la plupart des communications internes et externes sur le
contenu du projet sont réalisés par le Product Owner. Notez que le Scrum Master n'est pas
impliqué dans le contenu (la signification, l'estimation, la valeur commerciale, etc. des user
stories, ou le contenu des incréments).

Page 36
EXIN Agile Scrum
Manuel de Base

Rôle 3: L’équipe de développement (The Development Team)

Product Owner Scrum Master Development Team

1 personne 1 personne 3 à 9 personnes

à plein temps ou à temps partiel à plein temps ou à temps partiel à plein temps (recommandé)
Orienté Business Coach Scrum et facilitateur
Spécialistes

Les membres de l'équipe de développement sont des experts du domaine d'application et

sont responsables de la livraison des éléments du backlog et de la gestion de leurs propres
efforts.
Ils doivent être pluridisciplinaires: être capables de faire de A à Z chaque élément du
Product Backlog. Ils doivent être auto-organisés: trouver leur propre chemin au lieu de
recevoir des ordres. Ils doivent être alignés sur l'objectif du projet au lieu de travailler à
l'aveuglette. Une tâche peut être assignée à un seul membre pendant le Sprint, mais toute
l'équipe de développement restera responsable de cette tâche; aucun individu n’est
propriétaire d’aucune tâche.
L'équipe de développement livre le produit final du projet par incréments étape par étape.
Ils fonctionnent toujours d'une manière orientée produit.

Il est fortement recommandé aux membres de l'équipe de développement de travailler à

plein temps dans un seul projet, pour rester concentrés et agiles. La composition de
l'équipe de développement ne devrait pas changer fréquemment. S'il est nécessaire de
changer les membres de l'équipe, ce changement ne devrait pas se produire pendant un
Sprint. À tout moment, il y aura une baisse de productivité à court terme lorsque la
composition de l'équipe change.
Scrum est surtout efficace lorsqu'il y a 3 à 9 membres de l'équipe de développement. Pour
les grands projets, nous pouvons utiliser un modèle à l'échelle avec plusieurs équipes
Scrum.

Page 37
EXIN Agile Scrum
Manuel de Base

Autres Rôles
Vous pourriez avoir la tentation de donner aux membres de l'équipe de développement
des titres plus spécifiques, tels que concepteur, testeur, inspecteur qualité et chef
d'équipe; mais Scrum ne le permet pas! Tous les membres doivent avoir le même rôle et
le même titre: membre de l'équipe de développement.
Scrum est totalement dépendant de la collaboration et du travail d'équipe. Les membres
de l'équipe de développement doivent être unis et complètement alignés sur l'objectif du
projet. Si vous leur donnez des titres ou des rôles différents, ils se concentreront plutôt
sur leur propre rôle particulier dans le projet, et ils pourraient ne pas accorder
suffisamment d'attention au produit final. Chaque membre de l'équipe de
développement est responsable de toutes les données de sortie créées dans l'équipe de
développement, même si chacun d'eux peut être concentré sur un ensemble spécifique
de tâches.

Qui est le chef de Projet?

Maintenant que nous avons passé en revue tous les rôles Scrum, vous vous demandez
peut-être qui est le chef de projet?
La réponse est simple: un tel rôle n'existe pas dans Scrum; et aucun des trois rôles de
Scrum n'agit en tant que chef de projet traditionnel.
Certaines personnes considèrent le Scrum Master comme l'équivalent d'un chef de projet
traditionnel; mais ce n’est pas vrai, car les responsabilités du Scrum Master sont très
différentes de celles d’un chef de projet traditionnel. Les Scrum Masters ne sont pas
responsables de la planification, par exemple.
D'autres pourraient considérer que le Product Owner est l'équivalent d'un chef de projet
traditionnel, ce qui n'est pas non plus correct. Même s'ils sont responsables de certaines
parties de la planification et du suivi du projet, par exemple, la planification et le suivi sont
également partiellement assurés par l'équipe de développement. En plus de cela, la gestion
du cadre de travail est également une responsabilité de management de projet, qui est
effectuée par le Scrum Master.
Alors, une meilleure question à se poser est: qu'advient-il du management de projet?
Les responsabilités de management de projet sont réparties entre les trois rôles de Scrum
et il n'y a pas de management de projet centralisé dans Scrum.

Porcs et Poulets
Un porc et un poulet traînaient, quand le poulet leur suggère d'ouvrir un restaurant. «Que
devrions-nous servir?» demande le porc avec enthousiasme. Le poulet répond «jambon et
œufs». Le porc n'accepte pas, affirmant que «je serais engagé, alors que tu serais
seulement impliqué».
Toute l'équipe Scrum constitue les porcs dans cette analogie, tandis que le reste des parties
prenantes, y compris le client et le senior management, ne sont que des poulets.
Il est essentiel de différencier les porcs et les poulets dans tout projet, pour augmenter la
productivité. Les poulets n'ont pas d'autorité directe dans l'exécution du projet.

Page 38
EXIN Agile Scrum
Manuel de Base

Évènements Scrum

Introduction aux évènements Scrum

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

Il y a cinq évènements dans un projet Scrum:

1. Sprint: Chaque projet Scrum est un ensemble de Sprints. Un Sprint est un

conteneur pour les quatre autres événements (comme représenté dans le
diagramme ci-dessus), l'effort de développement et la maintenance du Product
Backlog.
2. Sprint Planning: la Sprint planning est le premier évènement dans un Sprint.
L'équipe Scrum planifie les éléments qu'ils vont livrer dans le Sprint et la façon
dont ils les livreront.
3. Daily Scrum: L'équipe de développement commence à travailler sur les objectifs
du Sprint dès que la planification du sprint est terminée. Pendant le Sprint,
l'équipe de développement tient une réunion quotidienne (15 minutes) pour
coordonner le travail pour les prochaines 24 heures. Cette réunion s'appelle le
Daily Scrum.
4. Sprint Review: Avant la fin du Sprint, l'équipe de développement présente
(démontre) le résultat du Sprint au client et reçoit des commentaires. Cette réunion
s'appelle Sprint Review (également connue sous le nom de Sprint Demo).
5. Sprint Retrospective: Après la Revue du Sprint et juste avant la fin du Sprint,
l'Équipe de Développement tient une réunion interne pour revoir le Sprint et
l'utiliser pour améliorer le processus (leçons apprises) dans le Sprint suivant. Cette
réunion s'appelle Sprint Retrospective.

Ces événements sont conçus pour permettre une transparence, une inspection, une
régularité et une adaptation critiques. Nous préférons utiliser ces réunions prédéfinies
avec des objectifs fixes et des durées maximales (timeboxées) plutôt que des réunions
ad hoc, qui nous font généralement perdre du temps.

Timeboxing
Il existe un concept essentiel dans les méthodes Agile, appelé timebox: une durée
maximale prédéfinie. Afin de maximiser la productivité, tous les événements Scrum
doivent être timeboxé.
La durée d'une timebox doit être convenue et fixée. Nous sommes libres de modifier la
durée en fonction des leçons apprises, mais pas fréquemment et jamais en fonction
d'occasions uniques.

Page 39
EXIN Agile Scrum
Manuel de Base

Par exemple, nous ne sommes pas autorisés à dire que "nous avons beaucoup à faire cette
fois-ci, alors augmentons la durée de cette timebox particulière". Ce que nous sommes
autorisés à dire, c'est que «sur la base des dix timeboxes précédentes, nous avons réalisé
que la durée de nos timeboxes n'est pas appropriée et qu'une augmentation de 30% de la
durée pourrait mieux répondre à nos besoins. Alors, augmentons la désormais ».

Espace de travail approprié

Les événements Scrum sont des outils de communication, et il est important de leur
préparer un environnement adapté. L'une des exigences est d'avoir l'équipe co-localisée
dans une seule pièce, au lieu de la répartir dans leurs départements organisationnels, par
exemple. Cela améliore la relation entre les membres de l'équipe et facilite leur
collaboration.

Communication Osmotique
La co-localisation des membres de l'équipe dans une seule pièce ne consiste pas seulement
à faciliter les conversations, mais aussi à faciliter les communications osmotiques, où les
gens peuvent obtenir des informations utiles en s’écoutant discrètement, et s'impliquer et
s'entraider au besoin.
Il est recommandé de maximiser les communications osmotiques. Cela se fait
principalement par une co-localisation appropriée, mais même les équipes réparties
peuvent en bénéficier en appliquant quelques règles simples; par exemple : chaque fois
que vous souhaitez envoyer un e-mail à un pair, mettez en copie tout le monde.
La co-localisation de l'équipe et la communication osmotique sont obligatoires dans la
famille Crystal des méthodologies Agile, y compris Crystal Clear.
Les méthodes Crystal sont davantage axées sur les personnes, l'interaction, la
communauté, les compétences, les talents et les communications en premier lieu que sur
les processus.

Management des équipes dispersées

Il est hautement préférable d'avoir des équipes colocalisées qui travaillent ensemble dans
une seule salle de projet. Cependant, il se peut que nous devions parfois avoir des équipes
dispersées, avec des gens dans d'autres villes ou même des pays. Dans le pire des cas, ils
peuvent vivre dans des fuseaux horaires totalement différents, ce qui rend la collaboration
beaucoup plus difficile.
Il est toujours possible d'utiliser Scrum avec des équipes dispersées, mais il faut tirer le
meilleur parti de la technologie moderne pour faciliter leurs interactions et s'attendre à un
niveau de productivité plutôt inférieur.

Évènement 1: Le Sprint

Sprint
Planning Daily Sprint Sprint
Scrum Review Retrospective

Sprint

Page 40
EXIN Agile Scrum
Manuel de Base

Chaque projet Scrum livre le produit en plusieurs itérations, appelées Sprints. Un

incrément est développé à chaque Sprint. Un incrément est une partie potentiellement
livrable du produit final. Un incrément est la somme de tous les éléments du Product
Backlog achevés jusqu'à présent dans un projet, et cet incrément ne cesse de s'agrandir
après chaque sprint. Par conséquent, vous pouvez considérez chaque nouvel incrément à
la fin d'un sprint comme une version mise à jour de l'incrément précédent avec de
nouvelles caractéristiques et fonctionnalités. Les incréments peuvent ou non être
réellement livrés (mis en service), mais devraient toujours être potentiellement livrables.
Les clients demandent généralement des modifications lorsqu'ils voient l'incrément
(pendant la revue de sprint), et nous ajoutons ces nouvelles demandes au Product Backlog.

Sprint #5 Sprint #6 Sprint #7 Sprint #8 Sprint #9

Increment #5 Increment #6 Increment #7 Increment #8

Sprint est un événement timeboxé, ce qui signifie que nous devons fixer sa durée au
début du projet et ne pas la modifier. Les sprints sont généralement fixés à un mois ou
moins.
Un point important est que nous ne modifions pas les éléments du Sprint Backlog après
que le Sprint est lancé, et les plans sont définis. Le Sprint Goal (discuté plus en détail dans
le Sprint Planning) ne devrait pas non plus changer. Le Product Owner et l'équipe de
développement pourraient essayer de clarifier et renégocier le périmètre au fur et à
mesure que l'on en apprend plus sur les éléments à livrer, mais ils ne changeront pas les
stories du Sprint Backlog. Même la composition de l'équipe de développement ne devrait
pas changer pendant un Sprint. Ces contraintes sont conçues pour permettre de se
concentrer et de faire avancer les choses.
Chaque élément (user story) du Product Backlog doit normalement être développé en un
seul Sprint car c'est beaucoup plus facile à gérer. Le Product Owner et l'équipe de
développement sélectionnent un certain nombre d'éléments en haut du Product Backlog
(cela a déjà été priorisé par le Product Owner) et visent à les faire «Terminer» (100%
achevés). Nous voulons qu'ils soient vraiment «terminés» lorsque le sprint est terminé et
qu'ils créent un incrément. Un incrément est la somme de tous les éléments terminés
créés pendant le Sprint en cours et tous les Sprints précédents.
Il est important de s'entendre sur une définition de «Terminé» (Definition of Done) au
début du projet. Nous n'appellerons pas quelque chose «fait», à moins que cela ne
corresponde à la définition. Un élément terminé à 99,999% n'est pas considéré comme
«terminé», il ne ferait pas partie de l'incrément et il ne serait pas démontré au client lors
de la revue de sprint.

Page 41
EXIN Agile Scrum
Manuel de Base

Définition de la Durée des Sprints

La plupart des entreprises utilisent des Sprint timeboxes de 2 à 4 semaines. Si nous utilisons
des Sprints de plus d'un mois calendaire, il est probable que les modifications non
appliquées deviendront suffisamment importantes pour créer des problèmes. Cela
augmentera la complexité et les risques. Par conséquent, nous devrions limiter les Sprints à
un mois calendaire. Les sprints ne doivent pas non plus être trop courts, car nous ne serions
pas en mesure de produire des éléments de Backlog achevés pendant le Sprint. Notre
objectif est de livrer le produit final élément par élément, à l'intérieur des Sprints; nous ne
voulons pas diviser un seul élément du Product Backlog en plusieurs Sprints.
Un autre point important concernant la définition de la durée des Sprints est la quantité
d'adaptation nécessaire pour le projet. Un projet avec des Sprints de deux semaines reçoit
presque deux fois plus de retours et d'opportunités d'adaptation qu'un projet avec des
Sprints de quatre semaines.
Nous ne modifions pas la durée des Sprints de manière ponctuelle. Par exemple : nous ne
sommes pas autorisés à dire que nous devons développer beaucoup de user stories cette
fois-ci, alors faisons un Sprint plus long. Cependant, si nous nous rendons compte que la
durée que nous avons choisie n'est pas appropriée pour le projet, nous sommes libres de la
réviser pour le reste des Sprints. Nous ne nous attendons pas à faire de tels changements
souvent.

Heures Supplémentaires, Tampons, etc.

Il y a deux questions courantes sur la gestion des Sprints:

• Sommes-nous autorisés à faire des heures supplémentaires pour terminer tous les
éléments du Sprint Backlog? Ce n'est pas interdit, mais fortement déconseillé. L'un
des principes Agile est d'avoir un rythme constant, de garder la qualité du produit et
le moral de l'équipe. Alors, ça vaut mieux éviter les heures supplémentaires. Notez
que le Sprint Backlog contient uniquement ce que nous estimons que nous pouvons
faire pendant le Sprint, et nous faisons de notre mieux pour tous les livrer, mais il n'y
a aucune garantie. Tous les projets présentent un niveau élevé d'incertitude, en
particulier les projets informatiques.
• Est-il possible d'avoir un tampon ou un temps de contingence pour les Sprints pour
s'assurer qu’on puisse tout terminer? Encore une fois, vous ne devriez pas vous
inquiéter de tout terminer. Le Sprint est timeboxé et nous ne le prolongeons pas,
même pas d'un jour. Il n'y a pas non plus de tampons à la fin des Sprints. L'équipe
peut préférer n'attribuer qu'un pourcentage de sa capacité (par exemple 80% ou
90%) pour développer les user stories et le reste pour les projets favoris, les spikes
(recherche sur le même projet), etc.

Annulation de Sprints
Même si les éléments du Backlog de chaque Sprint sont figés et ne changent pas, le Product
Owner a le pouvoir d'annuler un Sprint. Cela peut se produire lorsque l'objectif du Sprint
devient obsolète, en raison de changements dans le Product Backlog, les stratégies,
l'approche, etc. Lorsqu'un Sprint est annulé, les éléments qui sont «terminés» seront

Page 42
EXIN Agile Scrum
Manuel de Base

examinés et acceptés, et le reste des éléments (non commencés ou partiellement terminés)

seront remis dans le Product Backlog pour être traités ultérieurement.

Sprint 0
Il n'y a pas de Sprint 0, et il n'y a aucune différence entre le premier Sprint et le reste des
Sprints. Nous commençons simplement à fournir des incréments potentiellement livrables
dès le démarrage du projet et ne passons pas de temps à concevoir ou à préparer avant
celui-ci.
Eh bien, nous devons passer quelques jours au début, à créer un état initial du Product
Backlog, assez pour définir un ou deux premiers Sprints avant de démarrer les Sprints.
Cependant, cette durée doit être limitée, et nous n'attendons pas que chaque user story soit
définie et estimée, car il ne s'agit pas d'une approche adaptative.

Évènement 2: Sprint Planning

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

L'équipe de développement n'attend pas que le Product

Backlog soit planifié à 100% (toutes les exigences sont
rassemblées et clarifiées) pour commencer à
développer le projet. Dès que le Product Backlog est
suffisamment mature (dispose du nombre nécéssaire de
stories) pour fournir les informations pour le premier
Sprint, le Product Owner et l'équipe de développement
peuvent démarrer le premier Sprint.

La première chose à faire dans chaque Sprint est la planification de Sprint. La planification de
Sprint est une réunion timeboxée, généralement à huit heures de temps pour un Sprint d'un
mois, ou plus courte pour les Sprints de moins d'un mois. Les trois rôles devraient assister à
cette réunion.

L'équipe de développement doit estimer la capacité de travail qu'elle peut fournir en un seul
Sprint. Le Product Owner a déjà classé et ordonné le Product Backlog en fonction de la
valeur des éléments. Le Product Owner s'assure également que les éléments (stories) sont
faciles à comprendre. L'équipe de développement sélectionne ensuite un nombre approprié
d'éléments dans le haut du Product Backlog et les place dans le Sprint Backlog, à livrer dans
le Sprint en cours. La quantité de travail pour chaque élément est estimée par l'équipe de
développement et la quantité totale de travail des éléments de Product Backlog
sélectionnés est proche de la capacité estimée de l'équipe de développement.

Suite à la sélection des éléments, l'équipe Scrum doit rédiger un Sprint Goal. Le Sprint Goal
est un objectif qui doit être atteint dans le Sprint par la mise en œuvre du Product Backlog.
Le Scrum Goal fournit des conseils à l'équipe de développement sur les raisons pour
lesquelles il est en train de construire l'incrément.

Page 43
EXIN Agile Scrum
Manuel de Base

Voici un exemple de Sprint Goal:

Permettre à toutes les parties essentielles de la boutique en ligne de mettre en place un

processus d'achat complet. Cela rend les autres fonctionnalités du site Web plus
significatives pour le client.

Le Product Backlog doit être ordonné de manière à faciliter la définition des objectifs de
sprint, et la composition de l'objectif est de la responsabilité de toute l'équipe Scrum.
Le contenu du Sprint, qui est composé des éléments sélectionnés dans le Product Backlog,
peut nécessiter des ajouts de détails pendant le Sprint. Ces détails doivent être alignés sur
l'objectif de Sprint et, dans l'éventualité probable de renégociations, ils doivent être
effectués en présence du Product Owner. Le Sprint Goal est également inclus dans le Sprint
Backlog.
Lorsque les éléments à livrer sont sélectionnés et que l'objectif de Sprint est convenu, il est
temps de planifier comment livrer les éléments dans un incrément de produit «terminé» et
de réaliser l'objectif de Sprint. Ceci est la dernière partie du Sprint Backlog. La planification
du Sprint n'est pas nécessairement terminée lors de cette réunion. Avoir un plan détaillé
pour les premiers jours suffit; l'équipe de développement peut préparer des plans détaillés
pour le reste du travail plus tard.
Un plan détaillé est une ventilation d'un élément du Product Backlog en tâches détaillées qui
doivent être effectuées pour créer l'élément. Chaque tâche peut avoir des estimations, des
dépendances et d'autres informations similaires pour rendre le suivi possible.
Le Sprint Backlog sera prêt à la fin de cette réunion, et l'équipe de développement devrait
être en mesure de décrire les éléments qu'elle livrera au cours du Sprint et comment elle le
fera.

Page 44
EXIN Agile Scrum
Manuel de Base

Il n'y a pas de règle spécifique sur la documentation, le stockage et la présentation du Sprint

Backlog. Il peut être écrit sur un tableau similaire à celui illustré dans la figure suivante:

Les notes autocollantes jaunes sur le tableau ci-dessus sont des tâches créées en
décomposant chacune des user stories bleues. Ces tâches définissent ce que l'équipe de
développement fera pour livrer chaque élément, et elles sont responsables de leur
préparation. Certaines tâches sont créées lors de la réunion de planification du Sprint et
d'autres pendant le Sprint.

Le Sprint Backlog comprend les éléments suivants:

1. L'objectif du Sprint;
2. Les éléments sélectionnés du Product Backlog, à livrer pendant le Sprint;
3. Un plan détaillé pour transformer les éléments sélectionnés (stories) en incréments
«terminés» du produit et pour réaliser l'objectif du Sprint.

Comme vous pouvez le voir, les trois éléments du Sprint Backlog (l’objectif du Sprint, les
éléments du Product Backlog sélectionnés pour le Sprint et le plan détaillé) sont affichés sur
le tableau exemplaire. Cet exemple de tableau Scrum a également des fonctionnalités
supplémentaires pour suivre les tâches et les éléments dans les colonnes «À faire», «Faire»
et «Fait». La figure suivante montre le même Sprint une fois que le premier élément est
terminé et que les éléments n° 2 et n° 3 sont en cours.

Page 45
EXIN Agile Scrum
Manuel de Base

Vous pouvez également voir que des tâches supplémentaires ont été ajoutées aux
éléments les moins bien classés (éléments n ° 3 à n° 5). C'est ainsi que le plan détaillé du
Sprint évolue au fur et à mesure de sa progression.
Les éléments du Sprint Backlog ont généralement le même ordre qu'ils avaient dans le
Product Backlog, et par conséquent, l'équipe de développement doit d'abord travailler sur
les éléments classés plus haut.

Évènement 3: Daily Scrum

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

Le Daily Scrum est normalement une réunion de 15 minutes pour l'équipe de

développement afin d'inspecter le travail effectué depuis la dernière réunion, et de
synchroniser leurs travaux et de planifier pour les prochaines 24 heures. Il doit avoir lieu
quotidiennement.
Lors du Daily Scrum, chaque membre de l'équipe de développement doit répondre à ces
trois questions:

1. Qu'est-ce qui a été accompli depuis la dernière réunion?

2. Qu'est-ce qui sera fait avant la prochaine réunion?
3. Quels sont les obstacles sur le chemin?

Ils doivent évaluer les progrès vers l'objectif du Sprint et

prévoir la probabilité de terminer les éléments avant la fin
du Sprint.

Page 46
EXIN Agile Scrum
Manuel de Base

La Daily Scrum meeting doit se tenir au même moment et au même endroit tout au long
du Sprint, afin de minimiser la complexité. C'est juste pour l'équipe de développement; ce
n'est pas une réunion sur l’état d’avancement du projet pour toutes les parties prenantes.

L'équipe de développement doit également suivre la progression du Sprint chaque jour, et

par conséquent, c'est une bonne idée que le tableau de Sprint soit visible pendant la Daily
Scrum meeting. Ils peuvent utiliser un graphique Burn-Down pour suivre leur travail
restant et pour vérifier s'ils vont terminer tous les éléments avant la fin du Sprint.

La figure ci-dessus contient le Sprint Burn-Down Chart (les informations de suivi), qui peut
être mis à jour après chaque Daily Scrum meeting. Les graphiques Burn-Down sont abordés
plus en détail dans la section suivante.

Évènement 4: Revue de Sprint (Sprint Review)

Sprint
Planning Daily Sprint Sprint
Scrum Review Retrospective

Sprint

La durée de cette réunion est normalement de quatre heures pour un Sprint d'un mois. Si
les Sprints sont plus courts, la réunion sera proportionnellement plus courte.
À la fin du Sprint, l'équipe Scrum et les autres parties prenantes se réunissent et tiennent
une réunion de quatre heures pour présenter et inspecter les éléments «Terminés»
(l'incrément) du Sprint en cours. La présentation de l'Incrément lors de cette réunion a pour
but de recueillir des commentaires et de relever des demandes de changement dans les plus
brefs délais.

Page 47
EXIN Agile Scrum
Manuel de Base

Nous faisons bon accueil aux changements dans Scrum et les encourageons à être exigés,
car cela augmente la satisfaction du client et créera un produit final qui correspond mieux
aux besoins du client.

L'équipe de développement ne présente pas d'élément, à moins qu'il ne soit « terminé » à

100% sur la base de la Definition of Done convenue. Le Product Owner s'assure (avant la
Scrum Review) que les éléments présentés sont «Terminés». L'équipe de développement
démontre et explique les éléments.

Notez que la progression de 99% est juste 0% «Terminé». Il n'est même pas courant de
calculer des valeurs de pourcentage achevé dans les projets Agile, puisque la seule mesure
de la performance est le produit «Terminé». Il n'y a pas de quoi s'inquiéter, car les
éléments du Product Backlog sont généralement petits.

Toute user story qui n'est pas «Terminée» retournera dans le Product Backlog et le
Product Owner l’ordonnera à nouveau. S'il est toujours en haut du Product Backlog, il sera
sélectionné pour être achevé lors du prochain Sprint.

Le Product Owner discute du statut du Product Backlog et des dates d'achèvement

probables en fonction de la progression.

Statut Démo de
du projet l’incrément

Commentaires

Organisation Réalisatrice
Client

Finalement, l’ensemble de l’équipe Scrum collabore sur la révision du Product Backlog sur
la base de la donnée de sortie du Sprint, et les commentaires reçus du client.

Évènement 5: Sprint Retrospective

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

Page 48
EXIN Agile Scrum
Manuel de Base

Cette réunion dure normalement trois heures pour un Sprint d'un mois. Si le Sprint est
inférieur à un mois, la réunion sera proportionnellement plus courte.
Après la Sprint Review et juste avant la fin du Sprint, une autre réunion aura lieu, visant à
l'amélioration des processus (leçons apprises), qui s'appelle Sprint Retrospective.

Il y a une règle: nous devons toujours chercher des moyens de nous améliorer. Peu importe
à quel point l'amélioration est minime, il devrait y avoir une amélioration. Cette réunion est
une opportunité formelle d'amélioration, même si nous ne limitons pas notre amélioration
aux résultats de cette réunion. Nous examinerons (inspecterons) le Sprint, en ce qui
concerne les personnes, les relations, les processus et les outils, et identifierons les moyens
de les améliorer dans le prochain Sprint.

Activité: Raffinement du Product Backlog (Product Backlog Refinement)

Outre les événements timeboxés évoqués précédemment, il existe également une activité
continue dans les projets Scrum appelée Product Backlog grooming (Toilettage du Product
Backlog) ou Product Backlog refinement (Raffinement du Product Backlog). Il s'agit de passer
en revue et de réviser les éléments du Product Backlog, ce qui implique généralement l'ajout
de détails, d'estimations et d’ordre. Le Product Owner est responsable de la disposition
(priorisation) des éléments et l'équipe de développement est responsable de l'estimation.

La principale différence entre cette activité et les cinq évènements Scrum est que les
évènements Scrum sont tous timeboxés, mais le toilettage est une activité continue qui se
produit tout au long du Sprint. Cette activité ne doit pas consommer plus de 10% du temps
de l'équipe de développement.

Temps mort
Les sprints se succèdent, sans aucun relâchement, sur la base du Guide Scrum. Certaines
personnes préfèrent avoir un ou deux jours de congé entre tous les deux Sprints pour se
reposer un peu. Cependant, il y a quelques raisons contre la conception d'un temps mort
officiel dans le cadre de travail:

• L'équipe de développement est auto-organisée, donc si elle estime qu'elle doit

prendre quelques jours de congé, elle doit décider de le faire, au lieu que cela soit
institué dans le cadre de travail.
• De plus, avoir un rythme constant est essentiel, et nous ne nous attendons pas à ce
que les membres de l'équipe subissent des pressions anormales dans les Sprints et
aient besoin d'un repos spécial par la suite.

Artefacts Scrum
Les artefacts Scrum - résultats / produits de nos activités de management - sont conçus
pour accroître la transparence des informations liées à la livraison du projet et pour fournir
des opportunités d'inspection et d'adaptation.

Il y a six artefacts dans Scrum:

1. Product Backlog: Une liste ordonnée de tout ce qui (généralement des user stories)
pourraient être nécessaires dans le produit final;

Page 49
EXIN Agile Scrum
Manuel de Base

2. Sprint Backlog: les éléments sélectionnés du Product Backlog à livrer via un Sprint,
ainsi que l'objectif du Sprint et les plans pour livrer les éléments et réaliser l'objectif
du Sprint;
3. Incrément: l'ensemble de tous les éléments du product Backlog achevés jusqu'à
présent dans le projet (jusqu'à la fin d'un certain Sprint);
4. Definition of Done (Définition de « Fait » ou « Terminé »): la compréhension
commune de ce que signifie un travail «Fait»;
5. Surveillance de la progression vers un objectif: la mesure du rendement et les
prévisions pour l'ensemble du projet;
6. Surveillance de la progression du sprint: la mesure et la prévision des performances
pour un seul Sprint.

Les éléments 5 et 6 peuvent ressembler davantage à des activités, mais ils sont considérés
comme des artefacts dans le Guide Scrum, et par conséquent, nous les expliquerons dans ce
contexte. Vous pouvez imaginer leurs données de sortie (informations de suivi, graphiques
de Burn-Down, etc.) comme les vrais artefacts et ces deux éléments comme des activités
courantes (comme le Product Backlog grooming) ou comme faisant partie des événements
Scrum (Sprint Review et Daily Scrum).

Artefact 1: Product Backlog

Le Product Backlog est une liste ordonnée de tout ce qui pourrait être nécessaire dans le
produit final du projet. En d'autres termes, des parties du produit final attendu (une liste
de souhaits). Tous les éléments sont décrits dans un langage commercial simple, non
technique, et sont présentables à toutes les parties prenantes. Chaque exigence et chaque
changement dans le projet seront reflétés dans le Product Backlog.
Le Product Backlog évolue et s'améliore de manière dynamique; ce n'est jamais complet.
Nous n'attendons pas jusqu’à ce que le Product Backlog soit complet avant de commencer
à livrer les éléments. Le premier Sprint peut être démarré dès que le Product Backlog a
suffisamment de user stories définies.
Le Product Owner définit un certain nombre de facteurs pour déterminer la valeur de
chaque élément pour l'entreprise. Le retour sur investissement est généralement l'un des
facteurs. Tous ces facteurs seront résumés dans la valeur commerciale.
Les éléments du Product Backlog seront ensuite ordonnés en fonction de leur valeur
commerciale, de telle sorte que plus un article est haut, plus il sera livré tôt par l'équipe de
développement. Étant donné que les articles situés en haut du Product Backlog seront
livrés plus tôt, ils seront également plus détaillés et plus clairs par rapport aux éléments
plus bas.
Chaque élément du Product Backlog a également une estimation du travail. Ces
estimations sont uniquement effectuées par l'équipe de développement. Elles sont
utilisées par rapport à la capacité de l'équipe de développement dans un seul Sprint, de
déterminer le nombre d'éléments qui sera sélectionné pour ce certain sprint. Des
informations supplémentaires peuvent être ajoutées à chaque élément pour aider l'équipe
Scrum à prendre le contrôle.
L'équipe Scrum doit ajouter des détails, des estimations et ordonner les éléments du
Product Backlog tout au long du projet, ce qui s'appelle le Product Backlog grooming ou le

Page 50
EXIN Agile Scrum
Manuel de Base

Product Backlog Refinement. Il ne doit pas consommer plus de 10% du temps de l'équipe
de développement.
Le Product Backlog est créé sur la base de discussions plutôt que de documentation. Les
éléments du Product Backlog doivent être faciles à comprendre pour les parties prenantes
non techniques.

Parfois, plusieurs équipes Scrum travaillent sur le même projet. Le Product Backlog est une
représentation du périmètre du produit final et par conséquent, il ne devrait y avoir qu'un
seul Product Backlog, quelque soit le nombre d'équipes Scrum qui travaillent sur le projet.

Les éléments du Product Backlog

User Stories
Les type d'éléments les plus courants du Product Backlog sont les user stories, qui ont
été discutées dans les premiers chapitres de ce livre: En tant que [rôle], je veux faire
[quelque chose], pour [objectif].
Quelque soit le type d'éléments du Product Backlog que vous utilisez, ils doivent être
non techniques et indépendants. Certaines ressources suggèrent de suivre le guide
INVEST pour les user stories:

• Indépendant: si les éléments du Product Backlog ne sont pas indépendants, vous

ne pourrez pas les ordonner en fonction de leurs valeurs commerciales. Il est possible
de les rendre indépendants en les redéfinissant d'une nouvelle manière, et si ce n'est
pas possible, la dernière solution est de fusionner les éléments dépendants en un
seul.
• Négociable: les éléments du Product Backlog sont des outils de communication, et
en tant que tels ils doivent être négociables.
• Valeur: chaque élément doit avoir une valeur commerciale qui lui est attribuée, et
cette valeur sert de base pour ordonner les éléments dans le Product Backlog.
• Estimable: nous n'avons besoin que d'estimations fiables pour les articles en haut
du Product Backlog. Nous raffinons le reste des estimations dans l'activité continue
du Product Backlog grooming.
• Petit (Small): seuls les éléments en haut du Product Backlog doivent être petits; il
n’y a pas de souci au fait que les autres soient grands ou même peu clairs.
• Testable: le test fait toujours partie de la Definition of Done.

Les nouvelles user stories sont généralement grandes et peu claires. Après un certain
temps, nous pouvons passer plus de temps à les toiletter et à les transformer en user
stories plus petites, et enfin en stories claires.

Page 51
EXIN Agile Scrum
Manuel de Base

Epic User Stories

Les user stories qui sont trop grands sont appelées epic user stories. Il est normal d'avoir des
epic user stories au bas du Product Backlog. Le moment venu, nous devrions passer du
temps à toiletter ces éléments en les transformant en plusieurs user stories plus petites
mais indépendantes.

Thèmes
Les user stories doivent être indépendantes, mais nous avons généralement des groupes
d'éléments associés qui créent une capacité dans la solution. Ces groupes sont appelés
thèmes.
La compréhension des thèmes est utile pour planifier les releases et attribuer des valeurs
commerciales aux user stories individuelles.

Estimation

Story Points
L'estimation traditionnelle est basée sur les heures/homme ou les jours/homme. Une
estimation basée sur le temps crée un engagement de temps pour l'équipe et peut devenir
la raison pour les parties prenantes de remettre en question la performance de l'équipe.
Par conséquent, nous aurons deux problèmes majeurs:

1. L'équipe s’efforce à s'en tenir aux estimations initiales, ce qui pourrait réduire la
qualité. Nous ne devons jamais compromettre la qualité dans les environnements
Agile;
2. L'équipe apprend à ajouter des marges de sécurité à chaque estimation pour
éviter de futurs reproches. Ces contingences, appelées rembourrages (padding),
ne sont pas contrôlées et créent des problèmes. Pour commencer, nous avons le
syndrome de l'étudiant: le travail s'agrandit pour occuper le temps disponible.

Ainsi, nous n'utilisons pas d'unités basées sur le temps pour estimer les user stories. Au lieu
de cela, nous utilisons des unités basées sur l'effort complètement relatif qui ne montrent
que la quantité de travail requise pour une story par rapport à d'autres ou à une simple
story de référence. Cette unité est généralement appelée story point.
Nous commençons par définir une référence pour les story points; une user story simple qui
est claire pour tout le monde, et qui a été plusieurs fois faite auparavant, donc tout le
monde sait exactement combien d'effort il faut pour sa réalisation. Nous attribuons 1 story
point à cette user story, puis la comparons aux autres stories. Si, par exemple, nous pensons
qu'une certaine story nécessite dix fois l'effort de la story de référence, ce sera 10 story
points.
Il y a donc deux caractéristiques principales pour les story points:

• Ils sont basés sur l'effort plutôt que sur le temps;

• Ils sont relatifs.

Toute unité basée sur l'effort relatif peut être convertie en unités absolues basées sur le
temps, mais cette conversion est entièrement basée sur des statistiques. Par exemple, si
vous pouviez obtenir environ 100 story points dans chacun des Sprints précédents, vous

Page 52
EXIN Agile Scrum
Manuel de Base

pouvez vous attendre à ce que chaque story point prenne un centième de Sprint pour être
fait. Ce type de calcul est appelé mesure de vélocité et sera discuté sous peu.
Le story point de référence n'a pas à être une véritable user story du projet; juste quelque
chose d'assez petit, simple, clair et familier pour tout le monde.
Même si vous essayez d'utiliser une seule référence pour tous les projets de l'entreprise,
l'interprétation des story points dans chaque projet serait différente, car la composition de
l'équipe, les capacités du client et d'autres facteurs environnementaux pourraient être
différents.

Planning Poker
Il est de la responsabilité de l'équipe de développement d'estimer les user stories, mais
comment?
Tout le monde se rassemble et le Product Owner explique la user story pour s'assurer que
tout le monde comprend la story. Ensuite, l'équipe pourrait discuter de l'approche de
développement ou de tout autre aspect technique, et finalement voter.
Le point avec le mécanisme de vote est que si vous commencez par voter un par un,
chaque personne entendra l'opinion de tout le monde avant elle, et par conséquent, leurs
réponses pourraient être biaisées. Nous utilisons le planning poker pour éviter un tel biais.
La figure suivante montre un jeu normal de cartes de planning poker:

0 ½ 1 2 3 5 8 13 20 40 100 ?

Lors de l'utilisation du planning poker, chaque personne choisit une carte de planning
poker qui montre son estimation et la pose face cachée. Lorsque tout le monde sera prêt,
ils montreront les cartes en même temps. Si les valeurs proposées par différentes
personnes sont dans la même plage, la moyenne ou la moyenne des valeurs sera
l'estimation de la story. Cependant, s'il y a une grande différence entre les valeurs
proposées, cela signifie que tout le monde n'a pas la même compréhension dans l'équipe.
Par conséquent, nous en discutons à nouveau, apprenons les uns des autres et votons à
nouveau jusqu'à ce que les valeurs soient dans la même plage.

Y a-t-il une différence entre 40 story points et 41 story points lorsque nous estimons? Bien
sûr que non; c'est pourquoi nous n'avons pas toutes les valeurs dans les cartes de planning
poker. La meilleure option est d'utiliser la série de Fibonacci, dans laquelle chaque nombre
est la somme des deux nombres précédents:

Page 53
EXIN Agile Scrum
Manuel de Base

Séquence de Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …

La différence entre chaque deux nombres est vraiment appropriée. Cependant, les
valeurs elles-mêmes ne sont pas arrondies; alors, on peut les arrondir si on veut:

Une séquence de Fibonacci arrondie: 1, 2, 3, 5, 10, 15, 20, 35, 50, 100

La story de référence n'est pas toujours la plus petite story possible, nous ajoutons
donc également ½. Même dans ce cas, certaines stories peuvent être plus petites
que ½ story point, donc nous ajoutons également 0! Oui, zéro signifie que la story
est trop petite pour être estimée.
D'un autre côté, même 100 story points ou tout autre grand nombre pourraient ne
pas suffire pour certaines des epic user stories au bas du Product Backlog, nous
ajoutons donc également une carte ∞ (infini), qui montre que la story est tout
simplement trop grande pour être estimée et que nous devons la décomposer à un
moment donné.

Donc, ceci peut être un ensemble de cartes de planning poker:

0, ½, 1, 2, 3, 5, 10, 15, 20, 35, 50, 100, ∞

Cependant, vous pouvez utiliser toute autre séquence bien formée que vous voulez.

Vous n'avez même pas besoin d'utiliser des nombres pour estimer les story points.
Certaines équipes utilisent simplement les tailles de T-shirt:

XXS XS S M L XL XXL

Cependant, vous souhaiterez peut-être leur attribuer des valeurs numériques à un moment
donné. Cela facilite la session d'estimation pour certaines personnes.

Certaines équipes Agile utilisent des applications mobiles pour le planning poker. Ces
applications simples ne sont qu'un jeu de cartes: vous choisissez celle en laquelle vous
croyez et montrez votre téléphone portable lorsque tout le monde est prêt à faire de
même.

Triangulation

Lorsque nous comparons les story points avec la story de référence et que nous leur
attribuons des story points, nous nous attendons à ce qu'elles soient comparables les unes
aux autres. Par exemple, si la story A compte 5 story points et la story B 10 story points,
nous nous attendons à ce que B demande environ deux fois plus d'efforts que A pour
terminer.

Page 54
EXIN Agile Scrum
Manuel de Base

Aucune estimation n'est parfaite et vous pouvez parfois constater que les valeurs estimées
sont incompatibles. Pour en être sûr, vous pouvez faire une double vérification en
comparant des paires de user stories réelles entre elles et en effectuant des ajustements.

Une autre façon d'améliorer les estimations est d'avoir plusieurs user stories de référence
pour différentes tailles et de les utiliser toutes pour estimer chaque user story. Par
exemple, vous pouvez avoir une référence pour 1 story point et une autre pour 10 story
points. Lorsque vous comparez la story cible avec la première référence et que vous dites
que cela demande cinq fois l'effort (5 story points), vous devez également la comparer avec
la deuxième référence et voir si cela prend la moitié de son effort.

La plupart de ces prévisions supplémentaires pour augmenter la fiabilité des estimations,

ce qui implique de les comparer à plus d'une user story, sont appelées triangulation.

Tableau de Triangulation

Une très bonne pratique pour trianguler les estimations consiste à utiliser un tableau avec
des colonnes pour chaque valeur et à placer les cartes des user story (ou pense-bêtes) dans
différentes colonnes pour identifier leurs estimations. Dans ce cas, vous aurez une
comparaison complète entre toutes les stories, et vous pouvez facilement trouver les
incohérences et les corriger.

0 ½ 1 2 3 5 8 13 20 40 100
Item #23
Item #26

Item #28

Item #6

Ce type d'estimation est très similaire à l'estimation d'affinité expliquée ci-après.

Estimation d’affinité

L'estimation d'affinité est parfois un bon choix. Dans cette pratique, l'équipe commence
par trier les stories en fonction de leur effort relatif requis.

Stories plus petites Stories plus grandes

Page 55
EXIN Agile Scrum
Manuel de Base

Lorsqu'ils ont fini de discuter et de trier les éléments, ils les regroupent en lots de
valeurs estimées (story points).

Stories plus petites Stories plus grandes

1 SP 5 SP 100 SP
10 SP 40 SP
20 SP
3 SP

Heures idéales / Jours idéaux

Même si l'utilisation de story points est la méthode préférée, certaines équipes Agile
utilisent plutôt des «heures idéales» ou des «jours idéaux», car c'est plus simple à
comprendre et à expliquer. Dans ce cas, ils estiment le temps nécessaire à chaque user story
dans une situation idéale.
Lorsque nous commençons à travailler, nous pouvons mesurer la vélocité et comprendre
combien de temps idéal nous pouvons offrir à chaque Sprint. Par exemple, une équipe de 7
membres travaillant 20 jours dans un Sprint dispose de 140 jours réels dans chaque Sprint
(c'est-à-dire le temps écoulé), alors qu'ils pourraient ne pouvoir livrer que 100 jours idéaux
de story (c'est-à-dire le temps idéal).
Il est préférable d'utiliser des story points, car l'utilisation du temps idéal crée encore des
attentes qui, à leur tour, peuvent conduire à l'attribution de blâme.

Réestimation

Les estimations ne sont pas gravées dans le marbre et nous pouvons les réévaluer pour
corriger nos malentendus précédents ou pour refléter notre nouvelle connaissance accrue
du projet. Cependant, nous devons prendre en considération que toute l'influence de
l'environnement du projet est reflétée dans les calculs de vélocité, nous n'avons donc pas
besoin de les appliquer à l'estimation. Par exemple, si nous comprenons que le client n'est
pas aussi collaboratif que prévu, nous n'avons pas besoin de l'appliquer à l'estimation. La
plupart des erreurs d'estimation sont corrigées par les calculs de vélocité.

Les estimations ne sont qu'une comparaison de l'effort d'un story point à celui de la story
point de référence, et par conséquent, seule notre nouvelle compréhension de la quantité
d'effort relatif peut être la base d'une réestimation.

Dans la plupart des environnements Agile, seules les user stories du Product Backlog sont
réestimées, et dès qu'elles sont déplacées vers le Sprint Backlog ou sont terminées, nous
ne les réestimons plus.

Page 56
EXIN Agile Scrum
Manuel de Base

Disposition des éléments du Product Backlog

Il appartient au Product Owner de trouver la meilleure façon possible de disposer les

éléments du Product Backlog, mais les critères habituels sont liés aux concepts suivants:

• Avantages: quels sont les avantages de la solution? Les avantages sont définis en
fonction des stratégies organisationnelles et sont différents dans chaque
entreprise. Cependant, les avantages monétaires sont les plus courants.
• Coût: la quantité de ressources nécessaires pour l’élément ou le coût de
l'élément est également un point très important. Quelque chose peut être utile s'il
est possible de le développer avec un peu d'effort, mais pas si vous avez besoin
d'y consacrer beaucoup de ressources. Dans un environnement Agile, la
composition de l'équipe est fixe, le coût de chaque élément du Product Backlog
sera proportionnel à sa taille (par exemple en story points), et comme la valeur
commerciale peut être une valeur relative, vous pouvez remplacer simplement et
en toute sécurité le coût avec la taille.
• Risques: la disposition des éléments du Product Backlog est l'un des principaux
moyens de gérer les risques dans un projet Scrum

En général, la valeur commerciale est le rapport Bénéfices / coûts, et c'est pourquoi nous
devrions les considérer tous les deux. Il existe de nombreuses mesures combinant les
deux, telles que:

• ROI (retour sur investissement) - Le retour sur investissement pour une période
spécifique montre combien de votre investissement initial serait couvert par les
bénéfices. Par exemple. un ROI de 50% en un an signifie que vous récupérerez la
moitié de votre coût d'investissement en un an, en utilisant le produit. Des valeurs
plus élevées sont souhaitables. Ce critère est le principal et le plus courant pour
les projets Agile.
• VAN (valeur actuelle nette) - La VAN indique le montant total de l'investissement
moins les avantages acquis au cours d'une période donnée, et toutes les valeurs
sont actualisées pour tenir compte de l'inflation et des rentabilités. Par exemple :
une VAN d'un million d'euros en dix ans signifie que vous gagnerez un million
d'euros en plus de tout l'argent que vous aurez dépensé pour le projet, dans dix
ans. Des valeurs plus élevées sont souhaitables.
• Délai de récupération – le délai de récupération est le temps qu'il vous faut pour
gagner autant d'argent avec le produit que vous en avez dépensé pour le projet
pour le créer. Par exemple : un délai de récupération de trois ans signifie que vous
atteindrez le seuil de rentabilité de votre investissement en trois ans. Des valeurs
plus petites sont souhaitables.
• TRI (Taux Interne de rentabilité) - TRI est le taux d'actualisation dans lequel la
VAN devient nulle. Par exemple : si le TRI du projet est de 20% et qu'il existe un
système bancaire avec un taux d'intérêt de 20% ou plus, vous feriez mieux de
placer votre argent dans cette banque au lieu de l'investir dans le projet.

Page 57
EXIN Agile Scrum
Manuel de Base

Afin de calculer les métriques ci-dessus, nous pourrions avoir besoin de calculer d'autres
métriques, qui se concentrent uniquement sur le coût, au lieu d'une combinaison du coût
et des bénéfices. Par exemple:

• CTP (coût total de propriété) - Le CTP est une combinaison du coût de déploiement
et du coût de fonctionnement du produit. Le fait ici est que si vous réduisez le coût
de déploiement, vous risquez de vous retrouver avec un coût de fonctionnement
plus élevé et, par conséquent, vous devez les considérer ensemble avant d'affecter
un budget au déploiement.

Vous pouvez considérer les risques sur tous les calculs traditionnels et obtenir une valeur
commerciale totalement fiable (rapport bénéfices / coûts). Cependant, ce n'est pas facile
de le faire, et par conséquent, certains Product Owners préfèrent maintenir les calculs aussi
simples que possible et appliquent les risques en plus.

Notez que chaque estimation de la valeur commerciale est une estimation approximative
et que vous ne devez pas perdre de temps sur des détails inutiles qui n'apportent aucun
changement significatif.

Release Planning

Le corps principal du cadre de travail Scrum se concentre uniquement sur l'incrémentation,

et vous savez déjà que chaque incrément devrait être potentiellement livrable. Nous
pouvons souhaiter avoir des releases réelles avant la fin de certains projets pour que le
client commence à recevoir un retour sur leur investissement. En outre, un incrément livré
est utilisé plus sérieusement par le client et les utilisateurs finaux, et par conséquent, un
meilleur feedback sera recueilli.

Le planning des releases est effectué par le Product Owner, en collaboration avec le client et
les autres parties prenantes. Il n'y a pas d'artefact ou d'évènement formel pour le planning
des releases dans le Guide Scrum, et cela doit être fait dans le cadre des activités normales
du Product Owner.

Si vous prévoyez de procéder à la livraison de certaines releases, vous pouvez utiliser l'une
des options suivantes dans l'environnement Scrum:

• Avoir des releases ad hoc de temps en temps. Après tout, chaque Incrément est
potentiellement livrable et le Product Owner ainsi que le client peuvent décider s'ils
veulent publier l'incrément après la Sprint Revew.
• Avoir des releases à des intervalles prédéfinis; par exemple : tous les 3 Sprints. Dans
ce cas, vous souhaiterez peut-être faire une exception pour la première release,
pour vous assurer que l'incrément contient tous les éléments «Must Have». Dès
que vous avez la première release, vous pouvez avoir des releases régulières.
• Avoir des releases définies par les fonctionnalités nécessaires pour chacune d'elles.
Dans ce cas, vous pouvez définir un certain nombre de user stories pour chaque
release et livrez l'incrément dès qu'il possède toutes ces fonctionnalités. Il est
préférable de ne prévoir qu'une ou deux releases à l'avance pour garantir que le
projet reste adaptatif.

Page 58
EXIN Agile Scrum
Manuel de Base

Lorsque vous avez un plan de release, il est judicieux de mesurer la progression de la

prochaine release.

Artefact 2: Le Sprint Backlog

Le Sprint Backlog est créé pendant l'évènement Sprint Planning, qui est le premier
évènement d'un Sprint. Lors de l'évènement de Sprint planning, l'équipe Scrum collabore à
la création du Sprint Backlog, qui comprend les éléments suivants:

• Un certain nombre d'éléments sélectionnés en haut du Product Backlog, en

fonction de leur travail estimé et de la capacité estimée de l'équipe de
développement;
• Le Sprint Goal, qui aidera à décrire la signification réelle des éléments et à diriger les
efforts de l'équipe de développement;
• Un plan détaillé pour la livraison des éléments et la réalisation de l'Objectif de
Sprint pendant le Sprint. Ce plan détaillé continuera à être mis à jour pendant le
Sprint.

Les éléments du Sprint Backlog sont figés après le Sprint Planning, et l'équipe de
développement se concentrera sur la livraison d'un incrément de «Fait» basé sur ce plan. Les
éléments (user stories) du Sprint Backlog ne peuvent pas être ajoutés ou supprimés pendant
le Sprint. Cependant, il peut être nécessaire d'obtenir plus d'informations, de justifier ou de
clarifier certains éléments pendant le Sprint, ce qui doit être fait en présence du Product
Owner. Le plan détaillé, qui n'est normalement pas terminé à la fin du Sprint Planning,
continuera d'être mis à jour à mesure que le Sprint se poursuit.

Page 59
EXIN Agile Scrum
Manuel de Base

Dans des cas exceptionnels, lorsque tous les éléments sont terminés avant la fin du Sprint,
l'équipe de développement peut choisir l'élément suivant dans le Product Backlog et
commencer à travailler dessus pour la durée restante du Sprint.

Vélocité
La vélocité est le nombre d'unités de travail effectuées dans un certain intervalle. Dans le
cas d'un projet Scrum normal, il s'agit du nombre de story points que l'équipe peut réaliser
pendant un Sprint.

La vélocité est normalement calculée en faisant la moyenne du nombre de story points

réalisés lors des Sprints précédents. Certaines équipes préfèrent ne pas tenir compte des
premiers Sprints dans ce calcul, car ils ne sont généralement pas normaux. Certaines autres
équipes préfèrent calculer une moyenne pondérée, avec un poids plus élevé pour les
Sprints récents.

Par exemple:

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7

80sp 70sp 95sp 105sp 130sp 110sp 120sp

Dans ce cas, une moyenne simple est d'environ 100 story points. Si nous ignorons les deux
premiers Sprints, la moyenne serait d'environ 110 story points, ce qui est généralement
une meilleure mesure.

Evidemment, la vélocité change après chaque Sprint. Nous subissons généralement de

grands changements de vélocité au début du projet, mais après six ou sept Sprints, la
vélocité devient plus ou moins constante, parce que nous obtenons une performance plus
constante, et à cause de la nature du calcul de la moyenne.

Notez que nous ne comptons que les story points des user stories qui sont terminés jusqu'à
la fin du Sprint. Donc, si nous en avons presque terminé avec 10 story points, cela ne serait
pas compté dans la mesure de la vélocité. La story sera réestimée pour l'effort restant et
sera replacée dans le Product Backlog.

Nous utilisons la vélocité pour deux raisons:

1. À titre indicatif, pour estimer la quantité de travail que nous pouvons faire dans
le prochain Sprint. Si, par exemple, la vélocité est de 100 story points, l'équipe
choisira un certain nombre de user stories en haut du Product Backlog valant
environ 100 story points.
2. A titre indicatif, pour estimer la date d'achèvement du projet. Si la vélocité est de
100 story points, par exemple, et les story points restants dans le Product
Backlog valent 1000 story points, on peut estimer qu'il faut environ 10 Sprints
pour terminer le projet si on ne change pas beaucoup le Product Backlog.
Cependant, le Product Owner est responsable de tout prendre en considération
et n'utilise ce calcul que comme guide pour déterminer la date d'achèvement.

Page 60
EXIN Agile Scrum
Manuel de Base

Ainsi, en pratique, la vélocité est une valeur qui convertit les story points relatifs à l'effort
en temps. Un point important ici est que cette mesure prend presque tout en compte.
Par exemple, la quantité de collaboration du client affecte vraiment la quantité de
données de sortie que nous pouvons créer. Nous ne le considérons pas dans l'estimation
des story points (ce ne sont que des unités basées sur l'effort relatif), mais ils sont
contenus dans le calcul de la vélocité. Ainsi, lorsque nous allons choisir des stories pour le
prochain Sprint en utilisant la mesure de la vélocité, le nombre de user stories est
compatible avec la capacité de collaboration du client. Les mesures de vélocité
complètent les estimations en ajoutant tous les facteurs environnementaux.

Les informations sur les Sprints précédents, qui constituent la base du calcul de la
vélocité, sont appelées météo d'hier ou actualités d'hier.

Artefact 3: Incrément
Un incrément est une somme de tous les éléments du Product Backlog terminés à la fin d'un
Sprint. Chaque Incrément doit être «Fait» et doit être livrable. Le Product Owner peut livrer
ou non un certain Incrément, mais celui-ci devrait néanmoins être livrable (expédiable).

La figure suivante montre comment le nombre d’éléments dans le Product Backlog diminue
Sprint par Sprint, à mesure que le nombre de fonctionnalités dans les incréments augmente.

Product
Backlog Product
Backlog Product
Backlog Product
Backlog

Sprint #4 Sprint #5 Sprint #6 Sprint #7 Sprint #8

Increment #4
Increment #5
Increment #6
Increment #7

Notez que le concept d'incrément est cumulatif: chaque incrément contient également les
fonctionnalités des précédents.

Artefact 4: Définition de “Fait” (Definition of “Done”)

Il doit y avoir une compréhension commune de ce que signifie un travail «Fait». Cette
définition de «Terminé» doit être discutée et acceptée par l'équipe Scrum au début du
projet afin que les futurs incréments puissent être livrables.

Page 61
EXIN Agile Scrum
Manuel de Base

Lorsque plusieurs équipes Scrum travaillent sur un même projet, il peut ne pas être possible
d'utiliser la même Définition de «Fait» pour toutes les équipes, car elles peuvent travailler
sur des éléments de natures différentes. Dans un tel cas, chaque équipe Scrum définira sa
propre Définition de «Fait» et livrera ses éléments en fonction de cette définition.
Cependant, l'intégration de ces Définitions de «Terminé» devrait être capable de créer un
incrément potentiellement livrable au niveau du projet.

Une définition de fait contient généralement les éléments suivants:

• Processus de développement (spécification, conception, programmation,

intégration, test, documentation);
• Processus organisationnels (quelles choses supplémentaires vous pourriez avoir à
faire en fonction de vos directives organisationnelles);
• Exigences non fonctionnelles (performances, sécurité, évolutivité, maintenabilité,
utilisabilité, extensibilité, etc.);
• Critères de qualité (par exemple : normes de codage).

Sauf s'il existe une DoD standardisée dans l'entreprise, la composition d'une DoD relève de
la responsabilité de l'équipe de développement. Ils consulteront également le Product
Owner pour la DoD.

Documentation Agile
L'une des quatre déclarations du manifeste Agile est que nous valorisons des logiciels
opérationnels plus qu'une documentation complète.

C'est la tendance générale Agile pour éviter la documentation inutile. Après tout, de
nombreux documents de projet sont préparés pour être utilisés comme outils de
communication avec le client. Par exemple, une spécification d'exigences traditionnelle est
un document utilisé pour recevoir des commentaires du client. Cependant, nous pouvons
utiliser le logiciel opérationnel pour la collecte de commentaires, qui fonctionne beaucoup
mieux, et par conséquent, nous n'avons pas besoin d'une telle documentation. Sur la base
de notre méthode de livraison, nous n'avons pas de conception ni de planification à l'avance
et nous ne sommes donc pas en mesure de préparer de tels documents. Les exigences, la
conception et presque tout le reste évoluent tout au long du projet.

Outre la documentation basée sur la livraison qui est normalement absente dans les
projets Agile - à moins que nous ne soyons obligés de les avoir- nous avons également
d'autres documents tels que les manuels d'utilisation, la documentation de suivi et de
configuration, etc. Ce type de documentation est toujours nécessaire dans les projets
Agile, et nous les préparons toujours. Cependant, il n'est pas nécessaire de les avoir
comme documents; un manuel d'utilisation, par exemple, peut être une simple vidéo.

Un minimum de documentation est généralement nécessaire pour chaque user story, et

par conséquent, nous la mettons dans la Definition of Done.

Page 62
EXIN Agile Scrum
Manuel de Base

Test Agile
Il existe différents types de tests incorporer dans tout projet informatique, et comme nous
utilisons le développement itératif et incrémentiel, presque tous sont effectués dans le cadre
de Definition of Done; c'est-à-dire que nous n'attendons pas qu'un certain nombre de user
stories soient terminées avant d'exécuter un ensemble de tests.

Parce que nous devons exécuter des tests plus fréquemment, il est plus crucial d'avoir
des tests automatisés et tous les outils nécessaires pour cela. En plus de cela, nous
devrions augmenter la couverture du code autant que possible. La couverture de code,
ou la couverture de code de test, ou la couverture de test, est le pourcentage de code
impliqué dans les tests. Avec une couverture de code plus élevée, il est plus facile de se
fier au code.

D'un autre côté, imaginez les tests d'acceptation des utilisateurs. Est-il possible de
considérer une story comme terminée, si nous n'avons pas les tests d'acceptation des
utilisateurs? La réponse est généralement non. Dans ce cas, le test d'acceptation par
l'utilisateur doit faire partie de la Définition de fait et être exécuté pendant le Sprint.
Lorsque tout le reste est terminé, nous demandons au client de fournir des utilisateurs pour
les tests, alors que nous sommes encore au milieu du Sprint. Lorsque nous réussissons le
test, et tout le reste dans la DoD, nous pouvons appeler le Product Owner pour vérifier la
story et si c'est OK sur la base de la DoD, nous pouvons l'appeler Fait. C'est pourquoi nous
disons que le client doit collaborer dans des projets Agile.

Artefact 5: Surveillance de la Progression vers un objectif

Jusqu'à présent, nous avons utilisé le graphique Burn-Down pour visualiser la progression
du développement lors d'un Sprint. Vous pouvez également utiliser un graphique Burn-
Down pour visualiser la progression de l'ensemble du projet, c'est ce qu'on appelle le
graphique Burn-Down du projet.
Le Product Owner est responsable de la surveillance de la progression de l'ensemble du
projet vers son objectif. Cela devrait être fait au moins une fois par Sprint Review. Le
Product Owner détermine le volume de travail restant et le compare au travail restant des
Sprints précédents, et prévoit la date d'achèvement du projet. Toutes les parties
prenantes devraient avoir accès à ces informations.

Radiateurs d'information
Tout affichage d'informations de grande taille et très visible peut être appelé un radiateur
d'informations. Il peut s'agir de grands écrans ou de tableaux physiques, bien que la
plupart des personnes impliquées dans des projets Agile préparent des tableaux
physiques.
Les radiateurs d’information sont placés dans le lieu de travail commun, afin que toutes
les personnes concernées puissent voir et comprendre l'état du projet ou tout autre
message proposé par l'écran. Tout passant peut également le voir et le comprendre; cela
augmente la transparence du projet.

Page 63
EXIN Agile Scrum
Manuel de Base

Sur la base de la définition précédente, un tableau de Sprint bien entretenu peut

également être considéré comme un radiateur d'informations. C'est une combinaison de
plusieurs concepts (stories, tâches, objectif, DoD, progrès, etc.), alors que certains
radiateurs d'information ne sont focalisés que sur une seule information.

Un autre terme pour le radiateur d'information est le grand graphique visible.

Les schémas de radiateur d'information les plus courants sont expliqués ci-dessous.

Les Graphiques Burn-Down

Le graphique Burn-Down du projet montre la quantité de travail restant, au lieu de la
quantité de travail terminé; par conséquent, la ligne de performance réelle descend à
mesure que nous continuons et plus vite ça descend, plus nous serons heureux!

Story Poi nts Restants

500
Performance Réelle
450
400
350
300
250
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Temps

L'axe vertical (travail restant) montre la quantité de travail (qui est la somme de toutes les
estimations pour chaque élément du Product Backlog) et l'axe horizontal montre le temps
écoulé depuis le début du projet ou le nombre des Sprints passés.

Page 64
EXIN Agile Scrum
Manuel de Base

Nous ajoutons généralement une autre ligne pour présenter la distribution uniforme du
volume du travail sur le nombre initialement estimé de Sprints. Cette ligne agit comme
notre progression prévue, et sera utilisée pour comparer avec nos valeurs réelles.

Story Poi nts restants

500
Plan Initial
450
Performance Réelle
400
350
300
250 En Retard
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Temps

Story Poi nts restants

500
Plan Initial
450
Performance Réelle
400
350
300
250
En avance
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Temps

Dans le tableau ci-dessus, nous pouvons nous attendre à ce que le projet soit terminé plus tôt que prévu
initialement. Un calcul simple est présenté dans le diagramme suivant:

Page 65
EXIN Agile Scrum
Manuel de Base

Story Poi nts Restants

500
PlanInitial
450
Performace Réelle
400
350
300
250
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Temps

Donc, si nous n'avons pas beaucoup de changements dans le Product Backlog, le projet sera
terminé en 8 Sprints (nous sommes maintenant à la fin du sixième Sprint). Notez que toutes
les évaluations sont basées sur:
• Le nombre total de story points ou le volume de stories au lieu du nombre de
stories, car différentes stories nécessitent des efforts différents, et il n'est pas juste
de les compter comme des quantités égales.
• Les user stories Fait. Nous ne considérons pas les story points des stories qui sont
presque terminées mais qui ne sont pas terminées avant la fin du Sprint. 99% de
progression est 0% Fait.

Les Barres Burn-Down

La quantité de travail restante dépend à la fois des stories que nous avons réalisées et des
modifications que nous avons apportées au Product Backlog. Si nous essayons d'afficher un
simple graphique Burn-Down, il peut augmenter au lieu de diminuer dans un certain Sprint
où nous avons ajouté de nombreuses nouvelles stories au Product Backlog. Ce n'est pas
«faux», mais cela ne refléterait pas correctement les performances réelles.
Vous pouvez penser à plusieurs façons de visualiser les modifications du Product Backlog
avec les performances réelles, et l'une d'entre elles consiste à utiliser un type de graphique
généralement appelé Barre de Burn-Down:

600

500

400

300

200

100

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
-100

-200

-300

-400

Page 66
EXIN Agile Scrum
Manuel de Base

La ligne montre la performance réelle et chaque barre montre le volume des stories
restantes.

Le haut des barres change en fonction du volume des stories terminées uniquement, et par
conséquent, il ne fait que diminuer. Nous ajoutons généralement une ligne en haut des
barres pour mieux visualiser les performances réelles.

Les changements de volume des stories restantes dans le Product Backlog sont appliqués au
bas de la barre; ainsi, si nous ajoutons de nouvelles stories au Product Backlog, le bas de la
barre descend et nous aurons une barre plus longue. Si nous supprimons certaines user
stories, le bas de la barre remonte pour faire une barre plus petite.

La figure suivante montre un calcul simple de la date d'achèvement:

600

500

400

300

200

100

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
-100

-200

-300

-400

Donc, en supposant que nous n'aurons plus beaucoup de changements dans le Product
Backlog, le projet sera probablement achevé en 15 Sprints.

Les Graphiques Burn-Up

Tout type de diagramme qui montre le volume des stories terminées au lieu du volume
des stories restantes est appelé un graphique de Burn-Up, car la ligne ou la barre qui
montre votre performance augmente à mesure que vous travaillez.

Voici un exemple de tableau de Burn-Up:

Page 67
EXIN Agile Scrum
Manuel de Base

900

800

700

600

500

400

300

200
Défini
100
Fait
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

La ligne bleue montre le volume total de stories définies dans le Product Backlog jusqu'à
présent (y compris les éléments Terminés qui sont supprimés du Product Backlog). La ligne
noire montre le volume des stories Faites.

Comme vous pouvez le voir, la ligne bleue montre clairement la quantité de changements
dans le Product Backlog.

Un simple calcul de la date d'achèvement peut être effectué comme suit:

900
Défini
800
Fait
700

600

500

400

300

200

100

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Ce calcul est basé sur l'hypothèse que le volume des stories restants dans le Product Backlog ne changera
pas beaucoup.

Diagrammes de flux cumulatifs

Le graphique suivant présente un diagramme de flux cumulatif:

Page 68
EXIN Agile Scrum
Manuel de Base

1000 1000
En attente Fait
900 900
800 800
700 700
600 600
500 500
400 400
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

C'est un très bon moyen de démontrer les changements dans le Product Backlog, ainsi
que l'avancement du projet. Le seul inconvénient est qu'il s'agit d'un graphique de Burn-
Up au lieu d'un graphique de Burn-Down plus courant.
Afin de faire un calcul simple de la date d'achèvement, nous pouvons simplement utiliser
les dernières valeurs de Product Backlog comme indiqué dans la figure suivante:

1000 1000
En attente Fait
900 900
800 800
700 700
600 600
500 500
400 400
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Page 69
EXIN Agile Scrum
Manuel de Base

Sinon, si nous savons que le Product Backlog aura plus de changements, nous pouvons
également prendre en considération:
1000 1000
En attente Fait
900 900
800 800
700 700
600 600
500 500
400 400
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Comme vous le voyez dans la figure ci-dessus, nous n'avons pas inclus les premiers
Sprints dans le dessin de la ligne de tendance du Product Backlog, car nous avons
toujours beaucoup de changements qui ne sont généralement jamais expérimentés
dans le reste des Sprints. Cependant, la façon dont nous le calculons dépend
entièrement du jugement du Product Owner. Et enfin, rappelez-vous que le résultat
n'est toujours qu'un guide, et que le Product Owner n'est pas censé se limiter à un
calcul uniquement mathématique.

Calendrier Niko-niko
Tous les tableaux de bord d'informations ne concernent pas les performances du
produit; ils peuvent également couvrir d'autres aspects, tels que la qualité des
résultats ou même l'humeur et le moral de l'équipe. Les calendriers Niko-niko sont
utilisés pour ce dernier cas:

Il s'agit de n'importe quel type de calendrier et chaque membre de l'équipe exprime

son humeur en dessinant ou en attachant une émoticône sur le calendrier à la fin de
la journée.

Ces informations peuvent être utilisées par le Scrum Master pour trouver les causes
profondes de certains problèmes invisibles, ou par toute l'équipe Scrum dans la
rétrospective Sprint pour planifier des améliorations.

Page 70
EXIN Agile Scrum
Manuel de Base

Artefact 6: Surveillance de la Progression du Sprint

Outre la surveillance effectuée pour l'ensemble du projet, nous devons également
surveiller la progression de chaque Sprint tout au long de sa vie. Ceci est de la
responsabilité de l'équipe de développement et doit être effectué au moins une fois par
Daily Scrum.

Ces informations sont utilisées pour calculer la probabilité d'atteindre l'objectif du Sprint
et de terminer tous les éléments du Sprint Backlog.

Les informations sur la progression du Sprint peuvent être représentées par un graphique
Burn-Down, et ce graphique peut faire partie du tableau Sprint, que tout le monde peut
voir.

Cette mesure des performances est généralement basée sur les tâches plutôt que sur les
user stories, sauf si vous avez beaucoup de user stories dans chaque Sprint. Cette mesure
plus détaillée donne un graphique Burn-Down plus précis, ce qui est plus utile pour
maîtriser le Sprint.

Nous n'évaluons généralement pas les tâches, mais répartissons plutôt l'effort estimé de la
user story entre elles. Par exemple, si la user story comporte 10 story points et cinq tâches,
nous attribuons à chaque tâche 2 story points en moyenne. C'est ce qu'on appelle une
estimation descendante (top down).

Scrum à l'échelle (Scrum Scaled)

La taille de l'équipe de développement définie dans Scrum est comprise entre 3 et 9
personnes. Il s'agit d'une équipe très productive et très performante dotée d'un excellent
cadre de travail, capable de livrer le projet beaucoup mieux et plus rapidement que prévu.

Page 71
EXIN Agile Scrum
Manuel de Base

Cependant, cela pourrait ne pas suffire pour certains projets de très grande envergure ou de
taille moyenne qui doivent être achevés en peu de temps. Dans ce cas, nous pouvons utiliser
une version à l'échelle de Scrum avec plusieurs équipes.

Il n'y a pas de définition unique du modèle Scrum mis à l'échelle et diverses ressources le
définissent différemment. Cependant, l'idée principale est d'avoir une équipe Scrum
virtuelle, composée d'équipes Scrum réelles au lieu de personnes, et de gérer l'équipe
virtuelle comme une vraie équipe (pas dans tous les aspects, cependant). Si nous avons
besoin de plus de personnes dans le projet, nous pouvons également avoir une équipe
virtuelle d'équipes virtuelles.

Rôles
Chaque équipe a sa propre équipe de développement pluridisciplinaire, auto-organisée et
probablement un Scrum Master local. Certaines ressources suggèrent d'avoir des Product
Owners locaux, tandis que d'autres indiquent qu'il ne devrait y avoir qu'un seul Product
Owner pour l'ensemble du projet.
En plus des rôles standard de Scrum, nous pourrions également avoir ces rôles:

• Chief Scrum Master (c'est-à-dire Scrum des Scrums Master): il s'agit d'un Scrum
Master de haut niveau qui aide l'ensemble du projet à suivre le cadre de travail, en
collaboration avec les Scrum Masters locaux. Une personne peut être le Scrum
Master local pour plusieurs équipes, car être Scrum Master n'est pas
nécessairement un travail à plein temps.
• Chief Product Owner: c'est le rôle principal responsable du Product Backlog et qui
collabore avec les Product Owners locaux pour s'acquitter des responsabilités de
Product Owner du projet. Certaines ressources sont contre le fait d'avoir plus d'un
Product Owner, cependant, il semble irréaliste de s'attendre à ce qu'une seule
personne collabore avec des centaines de développeurs (en clarifiant les user
stories, par exemple).

Product Ownership
Peu importe le nombre d'équipes travaillant sur le projet; il s'agit toujours d'un projet, et
par conséquent, nous ne devrions avoir qu'un seul Product Backlog pour le planifier.

La partie délicate est de savoir comment répartir le travail entre plusieurs équipes. Certaines
entreprises le divisent en fonction des processus de développement; par exemple, avoir une
équipe pour la programmation, une autre équipe pour les tests, etc. Ceci n'est pas Agile, car
nous avons encore besoin d'équipes pluridisciplinaires. Un bon moyen de diviser le travail
est d'avoir, par exemple, une équipe pour la fonctionnalité Web, une autre équipe pour
l'application mobile, etc. Ou dans le cas d'une suite bureautique, nous pouvons avoir une
équipe pour le traitement de texte, une équipe pour le tableur, etc.

Certaines entreprises préfèrent avoir des équipes dédiées à une certaine partie du projet,
tandis que d'autres préfèrent le garder dynamique. Ainsi, dans le cas d'une suite
bureautique, nous pourrions préférer être capable de faire travailler toutes les équipes sur
le traitement de texte en un seul Sprint, car il a la priorité la plus élevée.

Comme nous gardons toujours les user stories du Product Backlog indépendantes, nous
pouvons en déduire que le travail des équipes est également indépendant; enfin, dans une
certaine mesure au moins.

Page 72
EXIN Agile Scrum
Manuel de Base

Nous n'imposons pas à toutes les équipes d'utiliser une seule Definition of Done, en raison
des différences potentielles entre leurs produits. Cependant, leurs Definitions of Done
devraient être compatibles, de telle sorte que lorsque nous combinons leurs données de
sortie, un incrément potentiellement livrable sera produit.

Scrum des Scrums

Les équipes ont des Daily Scrum, de préférence en même temps que les autres. Lorsque les
Daily Scrums au niveau de l'équipe sont terminés, un ambassadeur de chaque équipe
représente l'équipe lors d'une Daily Standup meeting de haut niveau appelée Scrum des
Scrums, pour coordonner les équipes.

Les ambassadeurs sont généralement l'un des membres de l'équipe de développement qui
est le plus impliqué dans la progression actuelle des objectifs du sprint; par conséquent,
nous pouvons avoir des ambassadeurs différents à chaque fois. Certaines équipes sont
habituées à ce que leurs Scrum Masters les représentent dans la Scrum des Scrums, mais
avoir une personne technique impliquée dans le développement est de loin préférable.

Chaque ambassadeur répond aux trois questions standard de daily standup, plus une
supplémentaire:
"Allez-vous mettre quelque chose à la disposition d'une autre équipe?"

Scrum de Scrums
Coordination
Parmi les équipes

Daily Scrums
Coordination
dans les équipes

Chaque équipe agit comme un membre virtuel dans une équipe Scrum virtuelle de niveau
supérieur, et par conséquent, nous ne pouvons pas avoir plus de 9 équipes multiples dans un
modèle Scrum mis à l'échelle à une seule couche. Cependant, nous pouvons ajouter une
nouvelle couche de mise à l'échelle au modèle et avoir jusqu'à 9x9 équipes (un max de 9x9x9
développeurs). Dans ce cas, nous aurions besoin d'avoir plusieurs Scrum des Scrums pour
chaque groupe d'équipes et ensuite un Scrum des Scrums des Scrums pour l'ensemble du
projet. Pour ce dernier cas, un représentant de chaque réunion Scrum des Scrums sera
présent.

Page 73
EXIN Agile Scrum
Manuel de Base

Scrum des Scrums des Scrums

Coordination
pour l’ensemble du
projet

Scrum des Scrums

Coordination parmi
les équipes

Daily Scrums
Coordination
dans les équipes

Certaines entreprises organisent des Scrum des Scrums tous les jours, tandis que
d'autres préfèrent en avoir une à deux fois par semaine.

Synchronisation
Il est préférable de synchroniser l'événement Scrum avec toutes les équipes, afin que
chaque équipe commence son Sprint en même temps. Leurs données de sorties créeront
un seul incrément à la fin de leur Sprint synchronisé.

Scission des équipes

Parfois, on ne sait pas au début que le projet nécessite plusieurs équipes. Peut-être qu'un
changement de stratégie, de valeur commerciale ou de marché vous convaincra de
consacrer plus d'efforts au projet et de créer plus de capacité. Dans ce cas, il existe
différentes manières de former les nouvelles équipes, notamment:

• Former des équipes entièrement nouvelles: c'est une bonne option lorsque
l'organisation est mature dans l'utilisation d'Agile. Cependant, les nouvelles
équipes ne sont pas suffisamment familiarisées avec le projet et cette solution
aura une inefficacité à court terme.
• Scission des équipes:
o Utilisation du modèle Split-and- Seed4: les équipes d'origine sont scindées
en plusieurs équipes dans ce modèle, et de nouveaux membres sont ajoutés
pour rendre les nouvelles équipes fonctionnelles et puissantes à nouveau. Le
point positif de ce modèle est que la connaissance du projet est répartie
entre toutes les équipes. L'inconvénient est que nous n'aurions plus l'équipe
d'origine, même si nous pourrions avoir consacré beaucoup d'efforts à son
team building.
o Utilisation du modèle Grow-and-Split: il est similaire au précédent, mais plus
progressif. Dans ce cas, de nouveaux membres sont ajoutés aux équipes
existantes jusqu'à ce qu'elles atteignent leur pleine capacité de 9. Ensuite,
nous scindons chaque équipe en deux, les laissons grandir et
éventuellement finissons par les scinder.

4
Les deux modèles de répartition des équipes expliqués ici sont empruntés à Réussir avec Agile, par Mike Cohn

Page 74
EXIN Agile Scrum
Manuel de Base

Les modèles Split-and-Seed et Grow-and-Split sont également utiles pour diffuser et

adopter le cadre de travail au sein de l'organisation (pour plusieurs projets): nous pouvons
commencer à essayer Scrum dans un projet pilote, et lorsque l'équipe devient compétente
dans la façon Agile de travailler, nous les scindons pour créer plus d'équipes et couvrir plus
de projets en utilisant le cadre de travail Agile.

Types de Contrat et Scrum

Vous pouvez être confronté à deux types de contrats dans un projet de développement
informatique:

• Temps et moyens ou unité fixe - c'est notre type de contrat préféré, qui est
compatible avec la nature adaptative du projet. Dans ce cas, nous pouvons soit
facturer le client en fonction des heures de travail, soit par Sprint (basé sur une
composition d'équipe et une durée fixes pour les Sprints bien sûr).
• Prix fixe - même si la plupart des clients aiment les contrats à prix fixe, les contrats
à contenu fixe et même certains d'entre eux sont tenus par la loi de n'avoir que
des contrats à prix fixe, ce n'est pas vraiment Agile. En effet, tous les contrats à
prix fixe sont basés sur une définition initiale du périmètre, ce qui est prédictif
plutôt qu'adaptatif. Le fait ici est que ce type de contrat est considéré comme
présentant un faible risque et un haut niveau de déterminisme pour les clients,
alors qu'en pratique, il n'en est pas ainsi pour les projets de développement
informatique. Malheureusement, il n'y a pas de vraie solution pour cela. Si vous
voulez être totalement Agile, vous ne pouvez pas avoir de contrat à prix fixe
traditionnel. Certaines équipes Agile ont du mal à rejeter de telles offres et ont
donc des solutions de contournement, mais aucune d'entre elles n'est assez
efficace.

Prérequis Scrum
Alors, comment pouvons-nous être Agile? Certaines personnes s'attendent à ce qu'une
équipe Agile soit suffisante, mais ce n'est pas le cas. Afin d'avoir un véritable
environnement Agile, quatre éléments sont requis:

1. Une équipe Agile - oui, bien sûr, nous devons avoir une véritable équipe Agile.
Dans le cas de Scrum, nous devons avoir:
a. Un Scrum Master expérimenté qui connaît assez bien le cadre de travail,
connaît les problèmes communs et a expérimenté des solutions efficaces
pour les résoudre, et est également un excellent facilitateur avec de hauts
niveaux de compétences interpersonnelles.
b. Un Product Owner expérimenté qui comprend les cycles de vie adaptatifs et
la valeur commerciale, et est disponible pour passer suffisamment de temps
avec le client et l'équipe pour résoudre les problèmes liés aux fonctions et
maximiser la valeur commerciale.
c. Une équipe de développement bien expérimentée, pluridisciplinaire et
auto-organisée qui sait développer de manière incrémentielle et itérative.

2. Un produit qui peut être produit de manière incrémentielle et itérative - tous les
produits n'en sont pas capables; prenons un bâtiment par exemple, pouvez-vous
Page 75
EXIN Agile Scrum
Manuel de Base

imaginer réaliser des incréments pour cela? Sinon, il n'est pas possible d'utiliser
Agile pour le construire. Certains projets liés à l'informatique sont également non
incrémentiels par nature, et par conséquent, vous devriez vraiment les étudier dès
le départ.

3. Une entreprise Agile - avoir une équipe Agile ne suffit pas; toute l'organisation
devrait également le comprendre et le respecter. Si les cadres supérieurs,
directeurs ou chefs de service ne sont pas disposés à responsabiliser l'équipe,
Scrum ne fonctionnera pas correctement.

4. Un client Agile - oui, il ne s'agit pas seulement de l'organisation réalisatrice; le

client doit également être Agile. Certaines attentes que nous avons d'un client
dans un environnement Agile sont:
a. Ils doivent être disponibles et disposés à passer du temps à collaborer avec
nous. Les commentaires des clients sont nécessaires pour l'adaptation.
b. Ils doivent comprendre la différence entre un environnement Agile et un
environnement traditionnel. Par exemple, ils ne peuvent pas s'attendre à ce
que nous leur donnions une planification ou une conception en amont.
c. Ils devraient être prêts à avoir un contrat de temps et de moyens au lieu
d'un contrat à prix fixe.

Malheureusement, il est très courant de nos jours que les clients s'attendent à ce que
l'organisation réalisatrice soit Agile, même s'ils ne sont pas prêts à en accepter eux-mêmes
les conséquences.

Il y a une différence entre «Agile» et «agile». Ce dernier exprime simplement le souhait

d'avoir le produit le plus rapidement possible, ce qui a toujours été un intérêt pour les
projets. Cependant, le premier est plus que cela; il s'agit d'adopter un cadre adaptatif et
d'accepter toutes ses conséquences, ce qui s'avère généralement plus rapide.
De plus, notez que les projets Agile sont plus rapides principalement parce que nous
aidons le client à comprendre la valeur commerciale des fonctionnalités et évitons de
perdre du temps à créer des fonctionnalités inutiles. Lorsque le client est obligé de vous
dire toutes les fonctionnalités à l'avance ou de se taire pour toujours, il utilisera toute sa
créativité pour réfléchir à toutes les fonctionnalités possibles. Il en résulte le fait évoqué
dans les premiers chapitres: en moyenne, environ 45% des fonctionnalités d'un logiciel ne
sont quasiment jamais utilisées.

Page 76
EXIN Agile Scrum
Manuel de Base

3
Kanban et ScrumBan

Page 77
EXIN Agile Scrum
Manuel de Base

Kanban
Le Kanban est une technique de management très appréciée dans le domaine de
l’industrie depuis longtemps et récemment utilisée dans des projets informatiques.
Cependant, ce que les gens entendent par Kanban dans les environnements informatiques
est généralement le ScrumBan décrit ci-après, au lieu d'un vrai Kanban. Kanban n'est
qu'une technique plutôt qu'un cadre de travail.

Il existe trois règles pour Kanban:

1. Le travail doit être visualisé

2. Les travaux en cours (WIP : Work in Progress) doivent être limités
3. Le travail doit être tiré (pull) au lieu d'être poussé (push)

Voyons maintenant comment cela fonctionne.

La visualisation est vraiment utile, car:

• Cela crée de la transparence et donc des commentaires et de la collaboration

• Cela crée plus de maîtrise

Ainsi, nous préparons un tableau Kanban et visualisons les étapes de travail et les éléments
de travail. Les étapes minimales dont nous avons besoin sont à faire, faire et fait. Dans un
projet informatique, vous pouvez visualiser votre Definition of Done au tableau; par
exemple : à faire, spécifier, concevoir, programmer, intégrer, tester, implémenter,
documenter. Il est plus courant de les faire simple comme faire, programmer, tester, fait
ou quelque chose de similaire.

Voici un exemple de tableau Kanban:

Page 78
EXIN Agile Scrum
Manuel de Base

Dans cet exemple, il y a 6 colonnes principales:

• À faire
• Conception, le WIP maximum (travail en cours) est de 2
• Programmation, le WIP maximum est de 3
• Test, le WIP maximum est de 4
• Documenter, le WIP maximum est de 3
• Fait

La limite optimale de travail en cours pour chaque étape est généralement déterminée par
essais et erreurs.

À l'exception des première et dernière colonnes, chaque colonne comporte deux sous-
colonnes: une pour les éléments en cours de traitement dans cette colonne et la seconde
pour ceux qui sont terminés à cette étape. Le point important ici est que les éléments des
deux colonnes sont comptés pour le travail en cours (WIP). L'autre point est qu'il s'agit
d'un système pull (tirer) plutôt que le système traditionnel push (pousser). Lorsqu'une
étape est terminée, les gens ne peuvent pas pousser le travail terminé dans la colonne
suivante et libérer de la capacité pour un nouveau travail; au lieu de cela, ils devraient
attendre que la colonne suivante prenne le travail en main. Ainsi, dans l'exemple ci-dessus,
toutes les colonnes sont pleines en fonction de leur WIP défini, et aucune nouvelle action
ne peut être entreprise.

Maintenant, disons que l'équipe de documentation a terminé avec l'élément G, donc ceci
se produit:

Voici les étapes exactes:

1. G est fait; il va donc dans la sous-colonne «fait» de la documentation.

Page 79
EXIN Agile Scrum
Manuel de Base

2. La Documentation étant la dernière étape, G ira automatiquement dans la

colonne principale Fait. Notez que si nous avons besoin d'une approbation, elle
doit être incluse dans la colonne existante ou avoir de préférence une colonne
séparée. Nous n'avons pas inclus une telle étape dans cet exemple.
3. Il n'y a désormais plus que deux éléments dans la colonne Documentation et par
conséquent, une capacité disponible. Les personnes de cette colonne tireront
l'élément J de la colonne précédente, car il a été marqué comme Fait pour la
colonne Test.
4. Maintenant que J est sorti, nous n'avons que trois éléments dans la colonne Test
et puisque le WIP est de 4, nous pouvons extraire L de la colonne précédente, qui
a été marquée comme Fait pour la Programmation.
5. Encore une fois, il y a un espace libre dans la colonne Programmation, afin qu'ils
puissent tirer l'élément N.
6. Désormais, les concepteurs ont également une capacité libre, ce qui leur permet
de tirer un nouvel élément de la colonne À faire.

Notez que tous les éléments de la colonne À faire doivent être triés en fonction des
critères qui conviennent à notre environnement, et nous devons essayer de conserver cet
ordre tout au long du processus. Il n'est pas toujours possible de garder l'ordre à chaque
étape, mais nous essayons quand même.

OK, voici l'état actuel:

Page 80
EXIN Agile Scrum
Manuel de Base

Certains éléments sont terminés dans chaque colonne après un certain temps et sont
déplacés vers la section "Fait" dans la colonne:

Nous ne pouvons pas avoir de changements sur le tableau pour le moment. Supposons
maintenant que les concepteurs ont également terminé avec l’élément T:

Page 81
EXIN Agile Scrum
Manuel de Base

Alors, que devrait-il se passer maintenant? Les concepteurs n'ont rien d'autre à faire et, en
fonction des règles Kanban, ils ne peuvent pas pousser le travail terminé dans la colonne
suivante, et comme ils n'ont pas de capacité libre, ils ne peuvent pas obtenir un nouvel
élément de la colonne À faire.

Dans ce cas, les concepteurs doivent passer à une autre colonne et aider leurs collègues.
Laquelle des colonnes? Le goulot d'étranglement est maintenant au niveau la colonne
Test.

Cela peut être le cas pour tout le monde dans l'équipe, si, par exemple, les autres colonnes
sont toutes complètes et pleines en termes de capacité, alors leurs membres doivent
également passer à la colonne Test. Même la personne dans la colonne À faire, que vous
pouvez considérer comme un Product Owner, devrait également passer à la colonne Test,
car peu importe les éléments qu'il / elle met dans la colonne, ils ne seront pas encore
développés.

Page 82
EXIN Agile Scrum
Manuel de Base

Ainsi, tout le monde travaille dans la colonne Test jusqu'à ce que le premier élément soit
terminé dans cette colonne et que le déroulement du processus redevienne normal. Puis
tous retournent à leurs colonnes d’origine et se concentrent à nouveau sur leurs
spécialités.

Comme vous pouvez le voir, les gens se concentrent sur la finalisation du produit, plutôt
que sur leurs activités spécialisées, qui sont principalement appliquées par le système pull.
Ce système peut être plus efficace en termes de productivité, même s'il peut sembler
étrange d'arrêter de travailler sur une colonne alors que vous pouvez réellement travailler.
De plus, le fait que nous nous attendons à ce que les gens passent à d'autres domaines de
spécialités dans certaines situations et aider leurs pairs semble inacceptable et improductif
pour certaines personnes. C'est parce qu'ils pensent qu'il faut avoir l'expertise pour faire le

Page 83
EXIN Agile Scrum
Manuel de Base

travail, ce qui est correct en général, mais nous insistons sur le fait que même les
personnes qui ne sont pas des spécialistes des tests peuvent aider les testeurs en
apportant leurs différents points de vue. Prenons par exemple la personne figurant dans la
colonne « À faire », qui est généralement une personne non technique et orientée
Business. Lorsqu'il / elle accède à la colonne Test, il/ elle pourrait se rendre compte qu'ils
peuvent augmenter l'efficacité en achetant des équipements plus puissants. Il/ elle calcule
donc le temps de retour sur investissement, par exemple, et voit que ce n'est que 8 mois,
ce qui est très bien. Ainsi, la personne se tourne vers la personne habilité, pour la
convaincre, afin d’obtenir le budget, pour acheter l'équipement et accélérer les activités
de test. Comme vous pouvez le voir, cette façon de travailler est une question de
rendement maximum et de travail d'équipe.
Vous devez réaliser que ce point de vue est vraiment proche de ce que nous avons dans les
environnements Agile tels que Scrum. Dans Scrum, par exemple, tout le monde est
responsable de tout, la propriété est partagée entre tout le monde, nous n'avons pas de
titres ou de rôles supplémentaires, et par conséquent, nous devons nous entraider autant
que possible. Un testeur dans un environnement Agile n'est pas seulement responsable
des tests, mais également de l'ensemble du produit.

ScrumBan

Il y a beaucoup de malentendus sur l'Agilité. Par exemple, la plupart des gens pensent
qu'ils peuvent simplement diviser leur périmètre prédictif en plus petits morceaux, les
développer pendant des périodes non timeboxées qu'ils appellent Sprints et l'appellent
Scrum, ce qui est totalement faux. Être Agile, c'est être adaptatif, plutôt que d'adopter un
certain ensemble de termes.

Mais, comment pouvons-nous être adaptatifs? Il y a beaucoup de conséquences et

d'exigences impliquées, et c'est pourquoi il est toujours préférable d'utiliser un cadre de
travail prédéfini au lieu de réinventer la roue. Chaque cadre de travail a un certain
ensemble de règles et de possibilités de personnalisation. Cette possibilité de
personnalisation est extrêmement faible pour Scrum, car elle est vraiment légère. Presque
tout est obligatoire dans Scrum et vous ne pouvez omettre aucun aspect. Mais certaines
personnes le font! Par exemple:

• Nous utilisons Scrum, mais nous ne gardons pas les Sprints timeboxés.
• Nous utilisons Scrum, mais nous définissons la durée du Sprint dans le Sprint
Planning.
• Nous utilisons Scrum, mais nous ne laissons pas évoluer le Product Backlog.
• Nous utilisons Scrum, mais nous ne jugeons pas nécessaire d'avoir des Sprint
retrospectives.

Tous ces cas sont appelés ScrumBut au lieu de Scrum. La règle est qu'un ScrumBut n'est
pas un Scrum. Un ScrumBut n'est pas un Scrum, car lorsque vous ne suivez que 95% des
règles Scrum, vous ne pouvez pas vous attendre à 95% de ses bénéfices; attendez juste
environ 20%.

Page 84
EXIN Agile Scrum
Manuel de Base

Il n'est pas faux d'utiliser une méthode non Agile; Les cadres de travail Agile sont de
bonnes solutions pour le développement informatique et certains autres types
d'initiatives, mais ce n'est pas le seul moyen. Vous n'êtes pas obligé de vous limiter à
Scrum, car d'autres cadres de travail Agile pourraient mieux fonctionner pour vous.

Dans certaines situations, Scrum ne semble pas être la meilleure solution possible. Lorsque
la maintenance est le seul objectif ou la partie la plus importante du travail, vous devez
répondre aux corrections de bugs ou ajouter des fonctionnalités urgentes dès que
possible, vous pouvez utiliser ScrumBan au lieu de Scrum.

ScrumBan est une combinaison d'un ScrumBut et d'un Kanban. Même si la plupart des
gens disent que c'est une combinaison de Scrum et de Kanban, ce n'est pas tout à fait
correct. Beaucoup de gens l'appellent simplement Kanban, ce qui n'est pas correct non
plus, car Kanban est une technique plutôt qu'un cadre de travail.

ScrumBan est un cadre de travail très simple: un ScrumBut, qui n'a pas de Sprints, plus un
système Kanban. Nous avons donc un tableau Kanban similaire à celui discuté dans la
section précédente, et un Product Owner avec les rôles et responsabilités standard gérant
la colonne À Faire (Product Backlog). L'équipe de développement sélectionne les éléments
en haut de la colonne À Faire chaque fois qu'ils ont de la capacité libre et les laissent
passer aux colonnes suivantes en fonction des règles Kanban.

Donc, la principale différence entre le type de ScrumBut que nous utilisons ici et un vrai
Scrum est que nous n'avons pas de Sprints. Cependant, quand avons-nous le reste des
événements? Voici comment nous le gérons:

• Réunion de planification (Sprint Planning): nous n'en avons plus besoin.

• Réunion de revue (Sprint Review): elle est toujours nécessaire et essentielle, car le
cadre de travail est néanmoins adaptatif, et nous avons besoin du retour client.
Les réunions de revue se déroulent comme suit:
o Soit après un certain volume de travail (par exemple après avoir développé
chaque 100 story points), ou
o À certains intervalles (toutes les trois semaines)
• Réunion rétrospective (Sprint Retrospective): elle est toujours requise, et elle
serait tenue après chaque réunion de revue.
• Daily standup (Daily Scrum): il est toujours nécessaire et se fait quotidiennement.

Et voici l'état des artefacts:

• Product Backlog: exactement le même que le Scrum Product Backlog. Il est

visualisé dans la colonne À Faire dans le tableau Kanban.
• Sprint Backlog: nous ne l'avons plus.
• Incrément: nous avons toujours la même définition pour les incréments et ils sont
le résultat que nous avons juste avant chaque réunion de revue.
• Definition of Done: exactement la même que le Scrum DoD.
• Surveillance de la progression vers un objectif: cette mesure du projet se fait
exactement comme nous la faisons dans Scrum.
• Surveillance de la progression du Sprint: nous ne l'avons plus.

Certains clients et Product Owners pourraient préférer ScrumBan, car il semble plus facile
à utiliser. Cependant, nous avons généralement un taux de productivité plus faible dans ce

Page 85
EXIN Agile Scrum
Manuel de Base

cadre de travail, car nous n'avons pas l'environnement sûr et calme créé par les Sprints.
Par conséquent, vous devez continuer à utiliser Scrum, sauf si vous devez vraiment passer
à ScrumBan.

Page 86
EXIN Agile Scrum
Manuel de Base

Le Voyage Commence

Nous espérons que vous avez trouvé le livre utile. Nous espérons également que vous
serez le prochain à adopter avec succès les cadres de travail Agile. N'oubliez pas que
devenir Agile nécessite un changement de mentalité.

Nous serions heureux de recevoir vos commentaires. Nos adresses e-mail sont
nader@mgmtplaza.com and frank@mgmtplaza.com.

Bonne chance

Nader K. Rad, Frank Turley

Page 87