MÉTHODOLOGIE

AGILE SCRUM
IV SCRUM : Planification Agile

L Dorian Lomendje
2
Confucius (孔子), 551 - 479 av. J.-C.

• « Je transmets, je
n’invente rien… »

« Ce n'est pas moi qui l'affirme, Dieu me

retourne, c'est Fucius qui l'a dit (et il avait
oublié d'être c…) »
Pierre Desproges
Aristote, 384 - 322 av. J.-C

• « Enseigner c’est dire

les causes pour
chaque chose »

Cité par Paul Jorion dans « Comment la

vérité et la réalité furent inventées »
Méthodologie Agile SCRUM
IV PLANIFICATION AGILE
1- LA RELEASE
Raison d’être de la planification de release
Le processus
 7

RAISON D’ÊTRE
 8

Raison d’être de la planification de release

• Plusieurs niveaux de compréhension de la notion de

planification :
• « Pas besoin de planifier : ça change tout le temps »
• « Il y a de la gestion de projet pendant le sprint »
• Pourtant le besoin de prévisions à moyen terme existe
• Il s’exprime par ce type de questions :
• Pourrons-nous utiliser <telle fonctionnalité> pour <tel événement> ?
• Dans combien de temps <telle fonctionnalité> sera-t-elle disponible ?
• Quel est le budget nécessaire pour développer <telle version> ?
 9

Définitions
• Une Release est la période de temps, constituée de
sprints, utilisée pour planifier à moyen terme
• La Vélocité est la mesure de la partie du Backlog de
Produit qui est réalisé par l’Equipe durant un Sprint. Les
mesures de Vélocité sont utilisées pour planifier
• Un Burndown Chart est une représentation graphique du
Reste à Faire dans une période, actualisé aussi souvent
que possible, et permettant de montrer la tendance
 10

Planifier la release
• La Planification de Release a pour objectif de fournir à
l’Equipe et aux Parties Prenantes des informations sur le
contenu des sprints constituant la release
• Les différences avec les approches classiques :
• Il y a deux niveaux de plan : le Plan de Release est à grosse maille
• Le plan n’est pas figé, il évolue
 11

Réunion ou processus ?
• En 2004, la Planification de Release est à peine évoquée
par Ken Schwaber dans son livre
• En 2009 Ken Schwaber la mentionne explicitement sur
son Guide Scrum
• Mais il ne la détaille pas beaucoup !
• De fait la Planification de Release est une des pratiques
Scrum les moins répandues
• En fait cette Planification de Release est plus un
processus qu’une seule réunion
Cas des releases multiples : la Roadmap
• Une vue qui présente
l’objectif et le contenu à
haut niveau des
Releases
• Elle montre pour chaque
Release ce qu’on prévoit
d’y faire en terme de
Features
• Elle apporte un horizon
de 6 à 8 mois, soit 3 à 6
Releases, selon leur
durée
Construction de la Roadmap
 14

LE PROCESSUS DE
PLANIFICATION DE RELEASE
 15

Le processus de Planification de
Release

1 Définir le 3 Définir la durée

critère de fin des sprints

2 Estimer 5 Planifier Plan de

Backlog
Backlog les stories la Release Release
estimé

4 Estimer la
capacité de l’Equipe
 16

Qui, Comment, Quand

• Toute l’équipe participe à la planification de la release
ScrumMaster et Product Owner compris
• L’estimation agile est faite par l’Equipe
• Ceux qui font sont les mieux placés pour connaître les difficultés
• La Release est planifiée à partir du Backlog de Produit
• Une liste de stories ordonnée par priorité
• La Planification de Release commence :
• Pour la première fois avant le début du premier sprint
• Ensuite quelques jours avant la fin du sprint
 17

Etape 1
Définir le critère de fin de la release
• Les choix possibles :
• Finir quand le Backlog est vide, ou quand un sous-ensemble
est développé
• Release à périmètre fermé
• La planification a pour objectif d’estimer la date de fin
• Fixer la date à l’avance
• On estime alors le contenu
• Plus « dans le style » de l’agilité
• Autres variantes possibles
• Attendre quelques sprints pour décider
• Arrêter quand le produit partiel a suffisamment de valeur
• Arrêter quand le budget est consommé
 18

Etape 2
Estimer les stories du backlog

• Estimer l’effort à fournir pour développer une story

• La technique n’est pas imposée par Scrum
• Une pratique courante : le planning poker …
 19

Le Planning Poker
• Il ne s’agit ni de poker, ni de planning
• C’est une séance d’estimation en groupe, avec des
cartes, qui combine le jugement d’expert (Delphi) et
l’estimation par analogie
• http://www.planningpoker.com
• http://mountaingoatsoftware.com
• http://tekool.net/blog/2009/07/21/printable-agile-planning-
poker
Estimation collective
 21

Déroulement du Planning Poker

• Chaque participant reçoit un
jeu de cartes
• Chaque carte a une valeur
possible d’estimation
• Le Product Owner présente la
story
• Les membres de l’Equipe
posent toutes les questions
nécessaires à une bonne
compréhension
• Tous les participants
présentent, en même temps
la carte choisie
• Le groupe discute des
différences éventuelles
Suite de
• On recommence jusqu’à
arriver à une convergence
Fibonnaci ++
• On passe à la story suivante

Etape 3
Définir la durée des sprints
• Les critères à prendre en
• Quelle durée pour les
itérations ?
• Pas de réponse universelle
• Le consensus :
• Toutes les itérations doivent
être de même durée
• Une itération est un bloc de
temps fixé
• Au début : un mois,
aujourd’hui 3-4 semaines
Une proposition :
•3 mois pour une release
•5 sprints dans une release
•2 semaines pour un sprint
22
compte
• L’implication des clients et
des utilisateurs (disponibilité)
• Le coût supplémentaire
engendré par le sprint
• La taille de l’équipe
• La durée maximum pour
prendre en compte un
changement
• La date de fin de la release
• Le maintien de la motivation
de l’Equipe
• La stabilité de l’architecture
 23

Etape 4
Estimer la capacité de l’Equipe
• Définitions
• La vélocité mesure la partie de Backlog réalisée pendant un sprint,
se calcule juste après la « Démonstration » lors de la revue de
sprint
• La capacité de l’équipe est une prévision de ce que l’Equipe est
capable de faire pendant un sprint
• La capacité se base sur la vélocité : elle se base sur le
principe de la « météo de la veille »
• L’Equipe devrait faire dans un sprint à peu près autant
qu’elle a fait dans le précédent
• Ici, comme ailleurs il ne faut pas confondre estimation et
engagement
 24

Etape 5
Produire le Plan de Release
• La méthode
• On prend le Backlog priorisé et estimé
• On commence par le premier sprint
• On y associe les stories en commençant par les plus prioritaires
• On continue jusqu’à arriver à la capacité de l’Equipe
• On passe au sprint suivant
• C’est le Sprint Mapping
• Certains outils le font automatiquement
• Une intervention manuelle peut être nécessaire !
• Quand cela ne « tombe pas juste »
• Quand certains ajustements s’imposent
Sprint mapping
 26

5 8
Planification de release 10

10 5 3
10

Sprint fini

Release
Sprint 1 Sprint 2 Sprint3 Sprint 4

Sprints
futurs
Vélocité
=10
Planification de release : les pratiques

A ESSAYER A EVITER
S’adapter au calendrier Confondre valeur et coût,
vélocité et productivité
Provisionner pour du Ne pas garder de mou pour
feedback ultérieur les incertitudes
 28

S’adapter au calendrier
• La pertinence de la vélocité repose sur une durée fixe des
Sprints associée à une composition de l’Equipe qui de
change pas :
• Des ressources identiques d’un Sprint à l’autre
• La planification, même agile, doit tenir compte des
événements connus à l’avance :
• Ponts, vacances …
• La durée peut exceptionnellement varier pour garder les
ressources à peu près stables pour tous les Sprints
• 6 personnes pendant 2 semaines
• 4 personnes pendant 3 semaines
 29

Confondre
• Valeur et Coût
• Une Story a deux attributs différents : un porte sur la Valeur, l’autre
sur sa Taille
• Deux Stories de même taille peuvent avoir des valeurs ajoutées
bien différentes
• Vélocité et Productivité
• La productivité est le quotient du résultat/temps passé
• L’estimation en points porte sur le coût de développement, la
vélocité aussi
 30

Ne pas garder du mou pour les incertitudes

• Dans le Plan de Release, tout est basé sur l’estimation
des Stories du Backlog
• Même si l’estimation est collective, une part d’incertitude
demeure
• Pour en tenir compte, il est indispensable de garder du
mou (buffer) dans les plans :
• Pour une release à périmètre fixé : le mou consiste en du temps
• Pour une release à date fixée : le mou porte sur des Stories
• Exemple : 10% de la durée du Sprint
 31

Provisionner pour le feedback ultérieur

• Une erreur classique : oublier le feedback
• Le feedback est une pratique essentielle du développement
agile
• Il permet d’améliorer le produit en prenant en compte les retours
des utilisateurs
• Encore faut-il ne pas l’oublier dans le Plan de Release
• La prise en compte concrète du feedback, ce sont de
nouvelles stories ajoutées dans le Backlog, qu’il convient
d’estimer et de prioriser
• Feedback
• Demande d’évolution sur des Stories existantes
• Nouvelles Stories
• Défauts (bugs) sur des Stories existantes
• Exemple : 15% de la durée du Sprint
Minimum Releasable Features
IV PLANIFICATION AGILE
2- LE SPRINT
La réunion de planification de sprint
 34

LA REUNION DE
PLANIFICATION DE SPRINT
 35

La raison d’être de la réunion de

planification de sprint
• Deux difficultés rencontrées :
• La réticence des programmeurs à l’engagement
• « Je vais essayer de terminer demain »
• La planification et l’estimation en solitaire
• « Les estimations n’étaient pas réalistes »
• Les méthodes d’estimation ont évolué
• Distinction entre estimation, cible et engagement
• Software Estimation / Steve McConnell / Microsoft Press 2006
• La Planification de Sprint est basée sur deux idées
• On ne peut pas prévoir de façon précise au-delà d’un certain
horizon, celui du Sprint
• Le travail du Sprint appartient à l’Equipe. Ce n’est pas un chef
qui définit ce qu’il y a à faire c’est l’Equipe qui s’organise elle-
même
 36

Planifier le Sprint
• Le dogme : il y a deux parties distinctes dans la réunion :
• La première pour avoir une bonne idée du périmètre et définir le
but du Sprint : le QUOI (What)
• La deuxième consacrée à l’identification des tâches nécessaires
pour l’atteindre et à leur estimation : le COMMENT (How)
 37

C’est l’Equipe qui planifie

• L’Equipe complète, Product Owner compris, participe à
toute la réunion
• La présence du Product Owner est souvent difficile à
conserver sur toute la durée
• Elle est pourtant nécessaire :
• Réponses aux questions de l’Equipe
• Engagement final sur le périmètre
 38

Le contexte : un espace de travail ouvert

• L’idéal est que l’Equipe dispose d’un espace de travail
ouvert :
• Une salle
• Avec des postes de travail favorisant la communication
(disposition)
• Une zone d’affichage (tableau)
• Un tableau de tâches mural sert à montrer l’avancement
des travaux durant le Sprint :
• C’est une représentation physique du plan de Sprint
• Elaboré pendant la Réunion de planification de Sprint
• Stories et Tâches sont représentées par des Post-it
 39

Contenu du Tableau
• Numéro du Sprint
• Date de début, Date de fin
• But du Sprint
• En-Tête de colonnes
• Etat des tâches : A Faire, En Cours, Fini
• En-Tête de lignes
• Les stories
• A l’intersection des lignes et des colonnes
• Les tâches
• On peut intervertir les lignes et les colonnes
 40

Tableau des Tâches vertical

 41

Durée de la réunion
• La Réunion de Planification de Sprint est une «TimeBox »
• Ken Schwaber donne une limite de 8 heures, 4 heures par partie
• Ces chiffres sont à ajuster en fonction de la durée du Sprint
• Quelques avis :
• Durée = 2 x n heures, où n est le nombre de semaines du Sprint
• Durée < 5% de la durée du Sprint
• Chute de motivation si plus d’une demi-journée

• Cette réunion est la première activité du Sprint qui

commence
 Réunion de planification de Sprint :
les étapes (7)

Rappeler
Evaluer le Définir le Identifier Estimer Prendre
le S’engager
périmètre but du les les des
contexte collectivement
potentiel Sprint Tâches Tâches Tâches
du Sprint
 43

Etape 1
Rappeler le contexte du Sprint
• Le Product Owner rappelle la place du Sprint dans la Release en
cours, il annonce la date de fin
• Si la durée n’est pas la durée usuelle, toute l’Equipe doit en connaître
les raisons
• Vacances
• Absences ponctuelles
• Jours fériés
• Et y adhérer !
• La disponibilité de chacun est alors connue
 44

Etape 2
Evaluer le périmètre potentiel
• Il s’agit de préciser le périmètre envisagé pour ce Sprint
• C’est-à-dire les éléments de Backlog de Produit qui vont être réalisés
• Le périmètre est défini en sélectionnant la première story en haut
de la liste ordonnée constituant le Backlog de Produit…
• …Et ainsi de suite jusqu’à ce que le total atteigne la capacité de
l’Equipe (en général 5 à 10 stories)
• Règle :
• Le Product Owner définit les priorités
• L’Equipe est la seule à décider du périmètre (arrêter d’en rajouter)
 45

Etape 3
Définir le But du Sprint
• Il s’agit de préciser en une phrase l’objectif principal du Sprint
(Mission)
• Il porte le plus souvent sur un domaine fonctionnel
• Au début du projet le but peut être orienté sur des considérations
techniques (Itération 0, Arbre de Noël)
 46

Etape 4
Identifier les Tâches
• La suite de la réunion a pour objectif de définir comment l’Equipe s’organise
pour réaliser les stories sélectionnées
• On part de la liste élaborée à l’étape 3
• Chaque story est présentée par le Product Owner, et
• Etudiée par l’Equipe qui identifie les tâches nécessaires à sa réalisation
• Ce qui force toute l’Equipe à discuter
• Deux types de tâches
• Les tâches induites des stories
• Toutes les activités liées au développement
• Les tâches indépendantes des stories (storyless)
• Pour une équipe de 5 personnes et des Sprints de 2 semaines, on pourra
avoir une quarantaine de tâches pour un Sprint
 47

Les types de Tâches

• Deux types de tâches :
• Les tâches induites des stories :
• Identifier toutes les activités liées au développement
• Et trouver comment les réaliser
• Conception par l’Equipe
• Les tâches indépendantes des stories (storyless). Par exemple :
• Préparation d’une démonstration
• Tâches relatives au déploiement
• Élimination d’obstacles
• Actions décidées lors de la rétrospective
• Actions pour améliorer la qualité du produit
• Les réunions, autres que les réunions Scrum, sur des sujets
techniques ou fonctionnels doivent apparaitre dans les tâches
 48

Etape 5
Estimer les Tâches
• L’estimation du temps à passer sur une tâche est faite
collectivement par l’Equipe
• Les tâches sont estimées en heures :
• Suffisamment petites pour être finies en une journée de travail
• Sinon il convient de la décomposer
• La liste des tâches n’est pas figée. Durant le Sprint, des tâches
peuvent être :
• Ajoutées
• Supprimées
• Décomposées
• Les équipes expérimentées peuvent se passer de l’estimation en
heure des tâches :
• Gestion binaire : Finie / Pas Finie
• 3 états : A Faire / En Cours / Finie
Un sprint planifié
 50

Etape 6
Prendre des Tâches
• Ce sont les membres de l’Equipe qui prennent eux-mêmes les tâches
• Il n’est pas utile d’attribuer toutes les tâches :
• Il suffit que chacun ait du travail pour les premiers jours du Sprint
• L’affectation des autres tâches peut être différée
• Cas des tâches pénibles dont personne ne veut :
• Il n’y a pas de tâches pénibles
• Sinon, elles seront courtes
• Les tâches sont moins ingrates quand elles ne sont pas imposées
• L’intérêt est plus explicite
• L’estimation est faite en commun
• L’affection n’est pas décidée à l’avance
• Il est fréquent qu’il faille revoir le périmètre après la décomposition en
tâches
• D’où la nécessité de la présence du Product Owner
 51

Etape 7
S’engager collectivement
• Pour finir la réunion l’Equipe s’engage à réaliser les stories sélectionnées
• L’engagement collectif est important pour motiver l’Equipe
• Il est préférable de détecter les réticences, et de les prendre en compte
avant de finir la réunion
• Avant de demander l’engagement le ScrumMaster annonce la capacité
prévue pour le Sprint :
• Calculée à partir des stories du périmètre
• Raisonnable par rapport à la vélocité moyenne des derniers Sprints
 52

Le plan de Sprint initial

• Le plan s’appuie sur la liste des tâches
• Une tâche est du travail à faire durant le Sprint
• La liste est produite pendant la réunion
• Chaque tâche peut avoir les attributs suivants :
• Un nom et la description du travail à faire
• La Story associée
• Le reste à faire estimé pour la tâche en heures
• La personne qui prend la tâche pour la réaliser
• Pour chaque Story on retrouve des tâches similaires
• Concevoir, coder l’IHM, coder la couche métier, faire les tests unitaires
• Les tâches seront prises d’une façon opportuniste durant le Sprint
 53

Plan de sprint initial

 54

Backlog et Burndown Chart actualisés

• A l’issue de la réunion de Planification de Sprint, le Backlog de Produit

est actualisé :
• Toutes les Stories associées au Sprint qui démarre changent d’état : elles
passent : « En cours »
• La mise à jour est l’occasion de prendre un cliché de l’état du
développement :
• La capacité que l’Equipe pense assurer
• Le reste à faire dans le Backlog de produit pour la fin de la Release
• Le nombre d’heures de travail à faire, en faisant le total des estimations de
chaque tâche
 55

Burndown de release
 56

Burndown de sprint
Réunion de planification de Sprint
les pratiques

A ESSAYER A EVITER
Préparer le Backlog en Décider du périmètre à la
anticipation place de l’équipe
Décomposer en tâches Ne pas laisser l’équipe
courtes identifier les tâches
Garder du mou Prendre un engagement
déraisonnable
Faire de la conception
 58

Préparer le Backlog en anticipation

• Une réunion de Planification de Sprint ne peut se dérouler
dans de bonnes conditions et aboutir au résultat souhaité
dans le « timebox » alloué que si le Backlog de Produit
est dans un état le permettant
• Cette préparation est un travail fait pendant le Sprint
précédent qui implique le Product Owner et l’Equipe
(durée raisonnable : 10% du temps de l’Equipe)
• Décomposer en histoire courtes
• Penser aux stories techniques et aux défauts
 59

Décider du périmètre à la place de l’équipe

• Ce n’est pas le ScrumMaster qui décide de ce qui doit
être fait
• Ce n’est pas non plus le Product Owner qui impose à
l’équipe le périmètre du Sprint
• Lors de la réunion le Product Owner présente les stories
par priorités décroissantes …
• … et l’Equipe dit STOP ! Quand elle pense que sa
besace est assez chargée pour le Sprint
 60

Ne pas laisser l’équipe identifier les tâches

• Identifier les tâches à l’avance serait un retour à un

schéma de gestion de projet avec un chef de projet
• La conception échappe alors à l’Equipe !
 61

Décomposer en tâches courtes

• Dans les méthodes traditionnelles les tâches sont souvent
plus longues que dans les Sprints :
• Plusieurs jours, voire plusieurs semaines
• Avec Scrum une tâche prend en général un jour
• Un bon principe est d’avoir une tâche finie le lendemain
du jour où elle a commencé
• Le constat peut ainsi être fait lors du Scrum quotidien
 62

Prendre un engagement déraisonnable

• Même sans la pression du Product Owner, une Equipe
qui débute peut pêcher par excès d’optimisme
• Et s’engager sur plus de Stories que ce qu’elle peut
raisonnablement réaliser en un Sprint
• Le périmètre sur lequel s’engage l’équipe est la Capacité
prévue. C’est à la fin du Sprint, lors de la Revue qu’est
mesurée la Vélocité réelle de l’Equipe
• Une Equipe doit apprendre à tenir ses engagements :
• Pratiques correctives lors de la Rétrospective
• Engagement raisonnable
 63

Garder du mou dans le plan de Sprint

• Pour empêcher les événements inattendus de mettre en
cause les engagements, il faut garder du mou lorsqu’on
planifie le Sprint
• Le mou c’est du temps non planifié qui reste disponible
pour pallier les impondérables
• Concrètement le mou est la différence entre les
ressources de l’Equipe et le total des heures associées
aux tâches du Sprint lors de la Réunion de Planification
• Les types de mou :
• Incertitudes dans les estimations
• Travail en anticipation sur le Sprint suivant
• Impondérables susceptibles de se produire
• Moyenne observée : 30%
 64

Faire de la conception
• Ne pas se lancer à corps perdu dans la réalisation des
Stories
• Il est nécessaire de faire de la conception
• Avec les méthodes agiles, la conception n’est pas faite
une fois pour toutes au début du projet, elle est faite tout
le temps
• Chaque Sprint comporte des activités de conception
• L’identification des tâches nécessite de réfléchir à la façon
dont une Story va être conçue :
• Discussion, diagramme de séquence
Sprint planning
Conclusion : le Planning dans Scrum