Agile Project Management &

SCRUM Framework

Présenté par: Inès BEN TARBOUT

 Maitre Technologue, ISET Radès
Responsable Pédagogique du Master professionnel en BADS, UVT
Responsable Pédagogique du Master professionnel en BI, ISET Radès
Consultante Formatrice en Data Management

Certifications:
PMI PBA- Professional in Business Analysis
PSM- Professional Scrum Master I
Artificial Intelligence Analyst, IBM 2019-2021
Présenté par: Inès Implementing Data Models and reports with Microsoft SQL Server
Implementing a Data Warehouse with Microsoft SQL Server
BEN TARBOUT Enabling Office 365 Services
Managing Office 365 Identities and Requirements
Implementing Microsoft Azure Infrastructure Solutions
Implementing a Data Warehousewith MS SQL Server 2014 (70-463)
Oracle Database 11g AdministratorCertifiedAssociate
Oracle Database SQL Certified Expert
Développement et mise en œuvre d’applications web avec vb.Net et Microsoft
Visual Studio.Net (70-306)
Développement et mise en œuvre d’applications Windows avec vb.Net et
Microsoft Visual Studio.Net (70-305)
Développement de services web xml et de composants serveur via Microsoft
vb.Net et l’environnement Microsoft .Net Framework(70-310)
 Mon parcours…
Présentations & Pour moi l’agilité c’est: …
SCRUM est…
Attentes A la fin de cette formation, je serai content si…
PLAN

01
• AGILITE: Vue d’ensemble

02
• Présentation générale de scrum

03
• SCRUM TEAM

04
• Artéfacts SCRUM

05
• Evènement SCRUM
Etat des lieux…

Qui, d’entre vous, gère des projets?

Etat des lieux…

Maintenance
•Complexe et couteuse

Fiabilité
•Produits souvent en panne

Couts
•Dépassement du budget prévu

Inadéquation/Non-
conformité
Délais
Produits ou services réalisés
différents des besoins des utilisateurs Produits souvent livrés en retard
Etat des lieux…

100%

90%
Livrés en retard

66%
Produits non réussis

54%
Livrés hors budget

30%
Abandonnés avant la fin
0%

Source: THE STANDISH GROUP 2003

La méthode en cascade C’est quoi?
La méthode en cascade
Etre AGILE …
L’AGILITE C’est quoi?
Pourquoi utiliser SCRUM?
La méthode en cascade
Waterfall vs AGILE
PLAN
A faire

Objectif du travail : Analyser les avantages et les inconvénients des deux

approches, en fonction de différents critères et réfléchir à l’adaptabilité de
ces méthodes à différents types de projets.
Consignes :
1. Étude comparative :
• Sélectionnez un type de projet dans le domaine de l'ingénierie (par exemple :
développement logiciel, conception d’un produit mécanique, projet de construction,
etc.).
• Comparez les deux approches (Waterfall vs. Agile/Scrum) pour ce type de projet.
Pour cela, vous devrez évaluer chaque approche selon les critères suivants :
• Flexibilité aux changements de besoins.
• Gestion des risques.
• Interaction avec les parties prenantes.
• Livrables intermédiaires.
• Délais de livraison.
• Qualité du produit final.
A faire

2. Analyse critique :
Basé sur votre analyse, identifiez les contextes dans lesquels chaque
approche serait plus adaptée :
• Quel projet conviendrait mieux à une gestion en cascade ?
• Quel projet nécessiterait une approche agile et pourquoi ?
Justifiez vos réponses en vous basant sur les caractéristiques du projet
et les avantages/inconvénients des deux méthodes.
A faire

2. Analyse critique :
Basé sur votre analyse, identifiez les contextes dans lesquels chaque
approche serait plus adaptée :
• Quel projet conviendrait mieux à une gestion en cascade ?
• Quel projet nécessiterait une approche agile et pourquoi ?
Justifiez vos réponses en vous basant sur les caractéristiques du projet
et les avantages/inconvénients des deux méthodes.
A faire
Exemple
Exemple
Les limites

• La gestion prédictive
fonctionne bien, à condition
d’avoir:

• Stabilité et prévisibilité
• Communication et
compréhension parfaite
• Choix parfaits dès le départ

AUCUN HUMAIN

UNE ALTERNATIVE : L’AGILITE

Le manifeste AGILE

« manifeste agile »:
• Un document révolutionnaire de gestion de projet initié
originellement dans le domaine informatique par 17 spécialistes des
logiciels et des frameworks; Ils y ont présenté 4 valeurs
principales et 12 principes
• Met davantage l’accent sur les individus et interactions humaines
plutôt que sur les processus et les outils.
• on reprochait souvent aux chefs de projets traditionnels, une certaine rigidité
et une certaine lourdeur dans l’application des processus qui venaient ralentir
les projets.
• Le manifeste agile a donné naissance à un courant de pensée qui s’est
démultiplié ensuite sur plusieurs approches dites « agiles »
(Scrum, Crystal, Extrem programming ou
XP, FDD, DSDM, AUP, Scrumban, etc.).
Le manifeste AGILE : « Les 4 valeurs agiles »
Le manifeste AGILE : « Les 4 valeurs agiles »
Le manifeste AGILE : « Les 12 principes du manifeste agile »
Le manifeste AGILE
Les limites
PLAN

01
• AGILITE: Vue d’ensemble

02
• Présentation générale de scrum

03
• SCRUM TEAM

04
• Artéfacts SCRUM

05
• Evènement SCRUM
Le Framework SCRUM

SCRUM est un framework

pour développer et maintenir
des produits complexes et
changeants.
Autrement dit, SCRUM est un
framework de gestion de
projet qui permet de délivrer
des produits de la plus
grande valeur ajoutée dans
une approche itérative et
incrémentale
SCRUM Value
Les 3 piliers de SCRUM

Le Framework SCRUM permet de travailler

en équipe pour faire de l’amélioration
continue sur des livraisons itératives
incrémentales de produits afin de satisfaire
vos clients.
SCRUM est soutenu par 3 piliers
fondamentaux:
• TRANSPARENCE : le fait d’être honnête,
de ne rien avoir à cacher, de travailler
ensemble au succès du produit/projet en
rendant les aspects importants du
processus visibles à tous ceux qui sont
responsables des résultats.
• INSPECTION : le fait de pouvoir
s’entraider et inspecter les artefacts
Scrum et l’état d’avancement par rapport
à un Objectif de Sprint afin de détecter
les écarts indésirables
• ADAPTATION : le fait de s’adapter aux
changements en général, changements
de produit, changements de façon de
faire…
Éléments du SCRUM
Eléments du SCRUM
Les limites
PLAN

01
• AGILITE: Vue d’ensemble

02
• Présentation générale de scrum

03
• SCRUM TEAM

04
• Artéfacts SCRUM

05
• Evènement SCRUM
SCRUM overview…
SCRUM Team
L’équipe SCRUM

• Habituellement, l’équipe SCRUM est composée de 10 membres au

maximum.
• Elle inclut 3. responsabilités (Accountabilities):
• Product owner: Optimiser et maximiser la valeur apporter par le produit en
répondant aux attentes des Stakeholders
• Scrum Master: veiller à la mise en application et au respect des règles de
scrum.
• Developers: réaliser le meilleur produit
• L’équipe Dev est:
• Multidisciplinaire (cross-functional): ses membres ont toutes les compétences
requises pour gérer de la valeur d’une façon continue
• Auto-gérée (self-managed): ses membres décident le Qui fait Quoi, Quand et
Comment
Le Product Owner
Le Product Owner

• La personne idéale pour jouer Bonne

connaissance
ce rôle devrait posséder les du domaine
compétences suivantes: métier

Maitrise des
Aptitude à la techniques
négociation de définition
de produit

Capacité à
Esprit ouvert
prendre des
au
décisions
changement
• Quelqu’un qui a été Analyste rapidement

métier (Business Analyst) est

Capacité à
un bon candidat pour ce rôle détailler au
bon moment
Le Product Owner

Comment choisir le P.O. d’une équipe?

• On peut se baser sur les compétences souhaitées du Product Owner déjà

présentées

• En effet, cette personne doit être:

• Une personne disponible
• Disponibilité continue

• Participation aux différentes cérémonies SCRUM

• Implication régulière : MAJ du backlog, ajuster les priorités, répondre aux questions, définir et aider aux
tests d’acceptation

• Une personne motivée pour ce rôle

Le Product Owner

• Le P.O. est le responsable du Product Backlog Management

Créer et S'assurer que le

Développer et
communiquer Ordonner les Product Backlog
Product Goal communiquer le PBIs Priorité Transparence
les Product PBIs est valide et bien
Product Goal
Backlog Items compris
Quelques conseils pour les P.O.

1. Se former au rôle de Product Owner

2. Collaborer avec l’équipe

3. S’impliquer dans les tests d’acceptation

4. Utiliser le produit

5. Impliquer les parties prenantes (ceux qu’il représente)

6. Planifier à court/moyen terme

7. Utiliser un outil pour suivre et gérer le backlog

Le Product Owner
Le SCRUM Master

Les responsabilités d’un SCRUM Master

Le travail et les
responsabilités d’un chef
de projet ne
2 disparaissent pas autant
dans les projets SCRUM.
Un des principes de SCRUM
Une grande partie est
1 SCRUM est l’auto- MASTER n’est
dévolue au Product
organisation. donc pas un
Pas de chef de projet Owner, la partie restante
Pas besoin d’un chef qui nouveau nom
dans SCRUM! est laissée à l’équipe et
assigne le travail à faire à pour chef de
Le rôle est éliminé au SCRUM Master
l’équipe projet!
Le SCRUM Master

Les responsabilités d’un SCRUM Master

Il a une grande

4
influence sur la façon
de travailler, sur le Le SCRUM
Le SCRUM Master a MASTER
processus, comme le
pour responsabilité pourrait être
Product Owner en a qualifié de
essentielle d’aider Process Owner
sur le produit par
l’équipe SCRUM et à équivalence
l’adapter au contexte.
Le SCRUM Master

Ken SCHWABER compare le SCRUM Master à un chien de berger qui veille sur son
troupeau

RESPONSABILITÉS:

1. Veiller à la mise en application du SCRUM (e.g Faire en sorte que les différentes
réunions aient lieu et qu’elles se passent dans le respect des règles)

2. Encourager l’équipe à apprendre et à progresser

3. Faire en sorte d’éliminer les obstacles qui pourraient freiner l’avancement

4. Inciter l’équipe à devenir autonome, autogérée et multidisciplinaire (e.g Protéger

l’équipe des interférences extérieures pendant le déroulement d’un sprint)
Le SCRUM Master

Les compétences

souhaitées d’un SCRUM

Master
Le SCRUM Master

Les collaborations

du S.M.
Le SCRUM Master

SERVANT LEADER

• Supprimer tous les obstacles pendant le processus de développement

• Aider à créer une culture collaborative et sûre au sein de l'équipe

Scrum et de l'organisation; Trouver et proposer de nouvelles solutions

qui contribueront à un développement plus efficace du produit

• Comprendre les besoins de l'équipe Scrum et de l'organisation et

comment ils peuvent être satisfaits en utilisant une approche agile.

Le SCRUM Master

TEACHER & COACH: Scrum Master doit utiliser ses compétences de coaching
et enseigner tout ce qui suit au quotidien.

Product Owner:
• Expression claire des business goals, du scope et du but du produit

• Gestion du Product Backlog en trouvant des moyens et des techniques plus efficaces.
Cela implique de s’assurer que les éléments du Product Backlog sont clairs et compréhensibles
pour tout le monde. Il doit être expliqué et organisé de manière à maximiser la valeur du travail
de l'équipe de développement.

• Comprendre et pratiquer l'agilité et l'approche empirique dans toutes les activités

Scrum.
Le SCRUM Master

Équipe de développement :

• Self-organization and cross- functionality qui sont essentielles à leur

croissance

• Comprendre le but du Scrum et le pratiquer de manière agile au

quotidien

• Créer des produits de grande valeur

• Résoudre les conflits et discuter des problèmes lorsqu’ils

apparaissent.
Le SCRUM Master

L'organisation :

• Comment Scrum peut être adopté et ce qui est exigé de l'organisation

• La valeur de Scrum dans l'organisation et que signifie utiliser un processus

empirique dans le développement du produit

• Planifier les implémentations de Scrum, coopérer avec d'autres Scrum

Masters pour accroître l'efficacité de l'adoption de Scrum dans
l'organisation

• Comment l'organisation doit interagir avec l'équipe Scrum et ce qui

augmentera sa productivité de ce qui ne fait pas.
Le SCRUM Master

FACILITATOR:

Le cadre Scrum se compose d'événements qui augmentent la communication et

l'efficacité au sein de l'équipe, comme: Daily Scrum, Sprint Planning, Sprint
Review and Sprint Retrospective.

• Scrum Master doit faciliter certains de ces événements en cas de besoin. Il doit
également s’assurer que les événements soient organisés et que l’équipe ne
dépasse pas le temps maximum dédié à chaque événement.

• Scrum Master doit savoir écouter les discussions de l'équipe et les problèmes
auxquels ils font face ainsi de savoir poser les bonnes questions au bon moment.
Le SCRUM Master: Conclusion

• Scrum Master : promeut Scrum et aide chacun à le comprendre et à le pratiquer

au quotidien.
• Il doit être le servant leader qui soutient le Product Owner, l'équipe de
développement et l'organisation dans leur parcours Scrum.
• Scrum Master est chargé d'aider le Product Owner dans la gestion du Product
Backlog et de s'assurer que tous les membres de l'équipe Scrum le comprennent.
• L'équipe de développement doit être coachée par le Scrum Master sur la manière
de devenir une équipe auto-organisée et cross-functional et de fournir des
produits à haute valeur ajoutée. Scrum Master doit les accompagner et
promouvoir une approche agile et collaborative.
• Scrum Master a de multiples fonctions telles que : servant-leader, teacher, coach,
facilitator et plus encore selon les besoins. Il doit être la personne qui s’adapte
rapidement au changement et aide tout le monde à le faire.
Le SCRUM Master

Les 8 positions d’un

SCRUM Master
Equipe de réalisation

Equipe de réalisation

Fait partie d’une SCRUM Sa composition ne doit pas

Regroupant tous A plein temps sur
Team changer pendant le sprint;
les rôles (cross- le projet de Self managed
Tout changement impactera
(10 membres max.) functional) préférence
sur la productivité
Equipe de réalisation

Les responsabilités de l’équipe

4
3
2 Chaque membre de
C’est l’équipe qui définit l’équipe apporte son
Dans SCRUM, l’équipe
elle-même la façon dont expertise;
1 s’organise elle même et
elle organise ses travaux; La synergie améliore
Son rôle est essentiel: doit avoir toutes les
ce n’est ni le scrum. l’efficacité globale
c’est elle qui va réaliser le compétences nécessaires
Master ni le product
produit, en développant au développement du
owner
un incrément à chaque produit: CROSS
sprint FUNCTIONAL
PLAN

01
• AGILITE: Vue d’ensemble

02
• Présentation générale de scrum

03
• SCRUM TEAM

04
• Artéfacts SCRUM

05
• Evènement SCRUM
…

3 artéfacts 3 commitments (engagements)

Product Backlog Product Goal

Sprint Backlog Sprint Goal

Product Definition of
Increment Done
Le Backlog du produit

Le Backlog du produit
Le Backlog du produit

Au départ, la difficulté
fondamentale est de transformer
l’idée de départ en quelque chose
d’utilisable par l’équipe de
Idée du projet
réalisation
Le Backlog du produit

Dans le projets traditionnels, cette transformation se

fait entièrement au début du projet et se concrétise
dans un document qui décrit: ce que va faire le
produit, ses fonctions et son comportement

Deviner et imaginer les détails du

comportement du produit avant d’entreprendre
aucune action
Le Backlog, la liste unique des stories

Le Backlog, la seule source de travail pour l’équipe de réalisation

(developers)
Priorité
décroissante A 3
2
Les éléments du On distingue:
B Un Backlog = liste Backlog sont Le Backlog de produit qui
énumère les exigences
ordonnée de appelés des PBI avec le point de vue du
C 1
toutes les choses à (Product Backlog client
Un Backlog = un Le Backlog de Sprint qui
faire (user stories, Item) contient les tâches de
D référentiel des
stories techniques, l’équipe pour le sprint
exigences courant
spikes …)
E
Le Backlog Produit
Le Produit Goal -> un « commitment »

• Le product Goal définit l’objectif/target pour l’équipe SCRUM

• Le product Goal est dans le Product Backlog
• Le Product Backlog peut évoluer pour satisfaire le Product Goal

Le Product Goal est un objectif à long terme pour l’équipe SCRUM

Elaboration d’un Backlog de Produit

La création et la maintenance d’un backlog de produit est une tâche

délicate menée par le Product Owner.

Différentes techniques peuvent être utilisées ou combinées:

• Utilisation des canevas (Vision Canevas, Product Canvas)
• Utilisation de la technique Story Mapping
• Utilisation de l’Impact Mapping
Utilisation des CANEVAS pour l’élaboration d’un Backlog de produit

• Définir la « Product vision »

• Définir le « Product Canvas » via:
• Créer les « Personas »
• Définir les « Features »/ « Themes »
• Détailler plus pour définir les « Epics »
• Construire le « Product Backlog » (définir les Product Backlog items)

• Prioriser le « Product Backlog »

Naissance du produit – en utilisant « Canevas »
Product Vision Board
Product Vision Board
Product Canvas: création du Product Backlog
Cycle d’Apprentissage continu en direct sur la base du product canvas
Exemple étape par étape
Product Vision

Product VISION
Product Vision Board: Hypothese initiales
Product Vision Board: Hypothese initiales
Product Vision Board: Hypothese initiales
Product Vision Board: Hypothese initiales
Product Vision Board: Hypothese initiales
Product Vision Board: Hypothese initiales
Product Vision Board: Hypothese initiales
Product Vision Board: Hypothese initiales
Product CANVAS

Product CANVAS
Product Canvas: Rappel
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Product CANVAS
Exemple réel de Product CANVAS sur tableau blanc
Elaboration d’un Backlog de Produit

La création et la maintenance d’un backlog de produit est une tâche

délicate menée par le Product Owner.

Différentes techniques peuvent être utilisées ou combinées:

• Utilisation des canevas (Vision Canevas, Product Canvas)
• Utilisation de la technique Story Mapping
• Utilisation de l’Impact Mapping
Le Story Mapping

• Le Story Mapping est une technique de gestion de produit utilisée

principalement pour organiser les fonctionnalités et les user stories
dans un cadre visuel. Il aide à :
§ Comprendre le parcours utilisateur : il met en lumière la façon dont un
utilisateur interagit avec un produit.
§ Prioriser les fonctionnalités : il organise les user stories par priorité et par
valeur.
§ Planifier le développement produit : il structure les fonctionnalités en
releases ou en incréments de valeur (MVP - Minimum Viable Product).
• Le Story Mapping se compose de :
§ Un parcours utilisateur (ligne horizontale) : représente les étapes que
traverse un utilisateur lors de l'utilisation du produit.
§ Des fonctionnalités ou tâches (verticales sous chaque étape) : représente les
actions que l'utilisateur peut entreprendre dans chaque étape du parcours.
§ Une priorisation des tâches : les éléments les plus importants ou prioritaires
sont placés en haut de chaque colonne, formant une hiérarchie des
fonctionnalités à implémenter.
Naissance du produit – en utilisant le Story MAPPING

Définition des personas

(exple: site ecommerce)
Naissance du produit – en utilisant le Story MAPPING

Création des User Journey

(exple: site ecommerce)
Naissance du produit – en utilisant le Story MAPPING

Identification des User Journey

(exple: site ecommerce)
Naissance du produit – en utilisant le Story MAPPING

Identification des Features/Thèmes

(exple: site ecommerce)
Naissance du produit – en utilisant le Story MAPPING

Identification des Features/Thèmes

(exple: site ecommerce)
Naissance du produit – en utilisant le STORY MAPPING

Identification des Features/Thèmes

(exple: site ecommerce)

EPICS
Naissance du produit – en utilisant le STORY MAPPING

Identification des Epics

(exple: site ecommerce)

EPICS

Features
Naissance du produit – en utilisant le STORY MAPPING

Découpage en user stories

(exple: site ecommerce)

EPICS

Features

USER
STORIES
Naissance du produit – en utilisant le STORY MAPPING

Découpage en user stories

(exple: site ecommerce)

EPICS

Features

USER
STORIES
Elaboration d’un Backlog de Produit

La création et la maintenance d’un backlog de produit est une tâche

délicate menée par le Product Owner.

Différentes techniques peuvent être utilisées ou combinées:

• Utilisation des canevas (Vision Canevas, Product Canvas)
• Utilisation de la technique Story Mapping
• Utilisation de l’Impact Mapping
Naissance du produit – en utilisant le Impact Mapping

• L'Impact Mapping est une technique de planification stratégique et

de communication qui aide à aligner les équipes de projet sur les
objectifs à atteindre et les résultats attendus.
• Il permet de visualiser les relations entre :
• Les objectifs d'affaires (le "Why")
• Les acteurs ou parties prenantes (le "Who")
• Les impacts que ces acteurs peuvent avoir (le "How"): les méthodes pour
arriver à l’objectif pour chacun de nos utilisateurs
• Les livrables ou solutions (le "What") qui aideront à atteindre ces impacts.
• L'objectif de l'Impact Mapping est de garantir que les équipes
travaillent sur les fonctionnalités ayant le plus fort impact sur les
objectifs stratégiques.
Naissance du produit – en utilisant le Impact Mapping
Naissance du produit – en utilisant le Impact Mapping
Naissance du produit – en utilisant le Impact Mapping
Business Model Canevas

• Le BMC est un outil visuel utilisé pour décrire et visualiser les différents
composants d'un modèle d'affaires.
• Il se concentre sur les aspects suivants :
§ Segmentation de clientèle
§ Proposition de valeur
§ Canaux de distribution
§ Relations avec les clients
§ Flux de revenus
§ Ressources clés
§ Activités clés
§ Partenaires clés
§ Structure de coûts

• L'objectif principal du BMC est de fournir une vue d'ensemble d'un

modèle économique afin d'identifier les interactions entre les différentes
composantes et d'assurer la viabilité de l'entreprise.
Business Model Canevas
Business Model Canevas
Business Model Canevas : Exemple
Business Model Canevas : Exemple
Résumé: BMC , Impact Mapping, Story Mapping

• Business Model Canvas (BMC) : Il définit les grandes lignes du modèle

d'affaires, y compris les segments de clientèle, la proposition de valeur et
les flux de revenus.
• Impact Mapping : Il aligne les fonctionnalités sur les objectifs
stratégiques, en se concentrant sur l'impact que l'on souhaite avoir sur les
acteurs clés.
• Story Mapping : Il détaille les fonctionnalités produit à développer en
fonction du parcours utilisateur et permet de prioriser les tâches en
fonction de leur valeur.

ces outils permettent une approche stratégique (avec le BMC et l'Impact

Mapping) et tactique (avec le Story Mapping) pour s'assurer que les efforts
de développement de produit sont alignés avec les objectifs d'affaires et
qu'ils apportent une réelle valeur à l'utilisateur final.
Iceberg du Backlog du produit
Iceberg du Backlog du produit
1. Epic :
• Dans un diagramme de cas d'utilisation, l'epic pourrait être assimilée à une
fonctionnalité globale ou un cas d'utilisation principal.
• Il s'agit d'un objectif ou d'un processus métier général que le système doit accomplir,
englobant de multiples cas d'utilisation plus spécifiques.
• Exemple dans un système de vente en ligne : l'epic pourrait être « Gérer les
commandes »
2. Feature :
• La feature correspond à un cas d'utilisation spécifique dans le diagramme.
• Chaque feature représente une fonctionnalité identifiable, plus détaillée qu'une epic,
mais toujours axée sur un objectif d'utilisateur.
• Elle implique généralement une interaction directe entre l'acteur et le système.
• Exemple dans le cas de "Gérer les commandes" : une feature pourrait être "Passer
une commande" ou "Traiter les retours".
3. User Story :
• Une user story est encore plus détaillée et représente des scénarios d'utilisation
spécifiques ou des interactions utilisateur dans le cadre du cas d'utilisation (feature).
• Ces scénarios décrivent comment un utilisateur utilise réellement la fonctionnalité
en question pour atteindre un objectif particulier.
• Exemple pour la feature "Passer une commande" : une user story pourrait être "En
tant que client, je veux ajouter un produit au panier pour pouvoir l'acheter plus tard"
ou "En tant qu'utilisateur, je veux valider mon panier pour finaliser ma commande".
La notion de priorités dans le Backlog

• Le backlog est la liste unique de tout ce qui est à faire, ce qui donne
beaucoup d’importance à la notion de priorité
• Cette priorité permet de constituer le flux de stories qui va alimenter
l’équipe. L’ordre peut changer tant que l’équipe n’a pas commencé à
développer la user story.
• Exemple:
• Dire que la user story A est plus prioritaire que la story B signifie que A sera
réalisée avant B

• Les priorités sont utilisées pour définir l’ordre de réalisation

Les critères de définition des priorités

Parmi les critères qui poussent à donner une grande priorité à une story:
• La valeur métier apportée (Business Value)
• La fréquence d’utilisation
• Le risque qu’elle permet de réduire
• L’objectif est de réduire l’exposition au risque le plus rapidement possible
• Des stories permettant de valider des choix techniques sont toujours prioritaires
• L’incertitude sur des besoins des utilisateurs qu’elle permettra de diminuer
• Quand un utilisateur désire une fonctionnalité mais ne sait pas de quelle façon le service doit
être rendu, la solution est de lui montrer rapidement une version pour obtenir du feedback
➤ s’offrir une occasion d’améliorer le produit
• La qualité à laquelle elle contribue
• Les travaux visant à garantir la qualité du produit devraient être prioritaires
• Les dépendances entre stories
Comment rédiger une bonne User Story ?

Selon Ron Jeffries(l’un des 17

signataires du manifeste agile,
une bonne User Story se
définit par l’addition de 3
composantes, nommé
les « 3C »:
CARTE+CONVERSATION+CON
FIRMATION.
Template d’une User Story
Exemple d’une User Story
Le narrative dans une user story

Il existe différents modèles de formulation

• Exemple:
En tant que <utilisateur>, je veux <verbe d’action> afin de <d’obtenir un
bénéfice>.
• On retrouve les 3 questions essentielles : POUR QUI ?, QUOI ? et
POURQUOI ?
• En anglais, cette narrative devient :
As a <type of user>, I want <some goal> so that <some reason>
Les notes dans une user story

• Les notes sont des éléments qui peuvent être utiles aux acteurs qui
réaliseront, testerons et validerons l’élément fonctionnel décrit.
• Dans une User Story et si cela apporte de la valeur à l’équipe de
réalisation, nous pouvons rajouter : le contexte, les règles de gestion,
les maquettes graphiques, les cas nominaux et aux limites,
la documentation à disposition en pièce jointe, les contraintes
techniques particulières, etc.
• Conseil: Pensez toujours à vos lecteurs et à la simplicité de votre
rédaction. Plus votre description sera longue, plus il y a de chance
qu’elle soit lue en diagonale… et donc que des choses soient négligées,
voire oubliées ! Soyez clair et efficace !
Les critères d’acceptation

• les critères d’acceptation permettent d’établir si l’élément

fonctionnel est « terminé », vraiment « terminé » !
C’est-à-dire que toutes les étapes de réalisation, de tests qualité et de
validation ont été mené correctement. La qualité est non négociable
en approche agile.
• Les critères d’acceptation précisent les limites et le comportement
attendus par l’applicatif. En réduisant le champ de l’incompréhension,
on améliore mécaniquement la qualité livrée.
• Conseil: Il faudra fournir des jeux de tests variés afin de couvrir
un maximum de combinaisons fonctionnelles, soit les cas les plus
fréquents, les cas aux limites, non-passants et les plus bizarres qui
pourraient créer des anomalies ou des comportements non-désirés.
Les tests sont l’une des clés de votre qualité !
En conclusion: Format des user stories
Quelles sont les caractéristiques d’une bonne User Story ?

une bonne User Story se définit par :

• Compréhensible par tous
Pas de terme technique, juste du langage naturel
• Raconte une histoire liée à un ou plusieurs utilisateurs.
Un parcours de bout en bout est préférable, même simple, et qui sera
enrichi par la suite.
• Légère et simple à rédiger.
Allez à l’essentiel, pas de baratin !
• Suffisamment claire
pour permettre aux développeurs d’estimer sa faisabilité
• Réalisable entièrement durant un sprint
Une limite de 3 à 4 jours de réalisation et de test est un bon repère.
INVEST-issez dans de bonnes User-Stories !

« INVEST » est l’acronyme inventé par Bill WAKE pour

retenir les caractéristiques d’une bonne User Story :
I – Indépendante : elle doit se suffire à elle-même, car les
dépendances avec d’autres user stories induisent des
problématiques de testabilité et de planification.
N – Négociable : elle doit amener à la discussion et peut-être
modifiée jusqu’à son inclusion dans une itération.
V – Valeur : elle doit apporter de la valeur à l’utilisateur final. La
notion de valeur étant toujours difficile à évaluer, la User Story doit
être exprimée avec une vision de l’objectif recherché pour
l’utilisateur.
E – Estimable : elle doit être suffisamment claire et comprise par
l’équipe pour que celle-ci soit en capacité de l’estimer.
S – Small : elle doit être de taille assez petite pour prioriser de
façon sûre et éviter les effets tunnels. Essayez donc au maximum
de découper finement vos user stories.
T – Testable : la User Story doit raconter une histoire, dont les tests
découlent de façon évidente.
Quand est ce qu’une user story est considérée comme ready?

Pour qu'une user story soit considérée comme "ready", voici les
critères à vérifier :
1. Respect des principes INVEST (Indépendante, Négociable, Valuable,
Estimable, Petite, Testable).
2. Critères d'acceptation clairs et validés.
3. Alignement avec les objectifs business et de produit.
4. Story décomposable en tâches ou sous-tâches réalisables en un sprint.
5. Estimable par l'équipe.
6. Aucune dépendance bloquante ou gestion des dépendances.
7. Clarté technique sur la façon de la mettre en œuvre.
8. Toutes les ressources nécessaires sont disponibles.
9. Respect de la Definition of Ready (DoR).
Si la user story satisfait à tous ces critères, alors elle est prête à être
sélectionnée pour le sprint et à être développée sans ambiguïté ou
blocage.
Cycle de vie d’un élément du B.P.

Crée par le PO (Il peut déléguer cette tâche à l'E.R.)

Accepté et priorisé par le Product owner

Estimé par l'E.R. dans une séance collaborative

Planifié associé à un sprint futur lors de la planification de release ou la

planification de sprint

En cours développé dans le sprint courant

Fini terminé, selon la signification de fini

Le backlog de sprint
Le backlog de sprint

Le Backlog du Sprint est composé de:

HOW
• Plan pour
WHAT préparer
• Ensemble l'incrément
des PBI à
WHY traiter

• Sprint Goal
Le backlog de sprint

Backlog du SPRINT
Le sprint backlog est un plan de travail crée par et pour l'équipe de réalisation

Il est créé durant la réunion de planification du sprint et peut être mis à jour au
cours du sprint (en cas de besoin ou une meilleure compréhension des PBIs
sélectionnés

En cas de besoin l’ER et le PO peuvent collaborer durant le sprint pour renégocier le

périmetre du sprint (scope)

Le sprint backlog inclut un engagement (commitment) pour le Sprint Goal (qui ne

doit pas être altéré)
Le product increment

Le product Increment
Le Product Increment

Product Increment
Chaque incrément est utilisable & apporte de la valeur ajoutée

Chaque incrément inclut les anciens incrément (intégrés)

Seul le travail respectant la « Definition of Doneé y est inclut

La Definition of Done est un commitment pour chaque incrément

L’incrément est considéré comme un point de validation vers le Product

Goal
Definition of Done

• La Definition of Done (DoD)

est une liste de critères que
doit respecter une User Story
pour être considérée comme
complété dans le cadre d'un
projet Scrum.
• Elle permet de garantir la
qualité et la cohérence des
livrables de l'équipe.
Critères communs dans la Definition of Done

1. Code écrit et revu: Le code a été écrit et soumis à une révision de

code (code review) par un ou plusieurs membres de l'équipe.
2. Tests unitaires: Des tests unitaires ont été écrits et tous les tests ont
passé.
3. Tests d'intégration: Les tests d'intégration nécessaires ont été
réalisés et validés.
4. Documentation: La documentation associée (technique et
utilisateur) a été mise à jour pour refléter les changements.
5. Fonctionnalité testée: La fonctionnalité a été testée et validée dans
un environnement de test ou de préproduction.
6. Intégration continue: La fonctionnalité a été intégrée dans le code
principal sans conflits, et le build a réussi.
7. Critères d'acceptation validés: Tous les critères d'acceptation
définis pour la User Story ont été vérifiés et validés.
Les evenements SCRUM
La réunion de planification de Sprint

La réunion de planification de sprint

Planifier le SPRINT

La planification de sprint
permet de répondre aux 1.
questions: pourquoi/ quoi/ Planification
comment de sprint

Why: définit le but du sprint

2. C'est un What: identifier le périmetre
Utiliser un tableau de tâche 4. Espace de
sert à montrer l’avancement évènement du sprint
travail How: identifier des tâches
des travaux répondant à
ouvert nécessaires pour l’atteindre –
C’est une représentation. 3 questions
le sprint backlog
Physique du plan de sprint

3. C'est
l'équipe Meme le P.O. participe à toute
complète qui la réunion
le planifie
Planifier le SPRINT: 3 questions

1. Why is the sprint valuable? – But du sprint

• Le PO discute de l’objectif que le sprint doit atteindre et des élément du
backlog de produit qui, s’ils sont complétés dans le sprint, permettent
d’atteindre l’objectif sprint.
• Toute l’équipe SCRUM collabore à la compréhension du travail à faire durant
le sprint
2. What can be done in this sprint? – Périmètre du sprint
• Le PO peut clarifier les éléments du backlog de produits sélectionnés et à
faire des compromis
• L’ER prévoit les fonctionnalités qui seront développées pendant le sprint
3. How will the chosen work get done? – Sprint backlog
• L’ER planifie le sprint en identifiant les tâches associées aux PBI séléctionnées
• Si l’équipe. De réalisation détermine qu’elle a trop de travail ou trop peu, elle
peut renégocier les éléments de backlog de produit sélectionnés avec le
propriétaire du produit
• L’ER peut également inviter d’autres personnes à fournir des conseils
techniques ou de domaine
Planifier le SPRINT

Capacité de
l’équipe
But du sprint

Backlog du
produit

Périmetre du
Conditions sprint
métier

Backlog du
Produit actuel
sprint

Technos
Tableau des tâches mural

1. Il est élaboré lors de la réunion

de planification de sprint

4. L’état des tâches est reconnu selon

2. Pour chaque PBI séléctionné
la place de la tâche dans des zones
l’equipe identifie les tâches
représentant chaque état: à faire, en
correspondantes
cours et finie

3. Sur le tableau, les stories et les

tâches sont placés avec des pos-it
Plan de SPRINT
Durée de la réunion

• La planification de sprint est une séance de travail collectif, limitée

dans le temps

• La durée de la réunion de planification de sprint est à ajuster en

fonction de la durée du sprint en question: limitée à 2*n heures, avec
n est le nombre de semaines dans le sprint

• Exemple: pour un sprint de deux semaine, la durée maximale de la

réunion est de 4 heures
En résumé

• La planification du sprint est la premiere réunion du sprint et la plus

délicate: son bon déroulement conditionne le succes du sprint
• Elle n’est pas une simple séance de planification mais aussi comme un
exercice collectif
• L’équipe apprend à s’auto-organiser et à partager la connaissance sur
le produit
• A la fin de la planification, on a:
o Un but pour le sprint
o Une liste des membre d’équipe (et de leur niveau d’engagement, si ce n’est
pas 100%
o Un backlog de sprint (la liste des stories incluses dans le sprint)
o Une liste des tâches
o Une date bien définie pour la démonstration
o Une heure te un lieu bien définis pour le scrum quotidien
Le Daily Meeting

La mêlée quotidienne ou Daily meeting

Une réunion quotidienne

• Le scrum quotidien est un point de rencontre ou tous les membres de

l’ER examine de près l’avancement envers le sprint goal
• Ils apportent, éventuellement, les modifications nécessaires au
backlog du sprint
• Son but principal est d’optimiser la probabilité que l’équipe atteigne
les objectifs du sprint
• Les moyens pour atteindre ce but consistent en:
• Eliminer les obstacles nuisant à la progression de l’équipe
• Garder l’équipe concentrée sur l(objectif du sprint
• Evaluer l’avancement du travail pour le sprint en cours
• Communiquer objectivement sur l’avancement
Apres le premier sprint quotidien
Apres quelques sprints quotidiens
En résumé

• Le daily meeting est une réunion qui se passe :

• Tous les jours

• Fait le point sur le travail effectué et celui à faire

• Permet à l’ER de s’auto-gérer pour mieux atteindre l’objectif du sprint

• C’est une pratique qui a prouvé son efficacité et qui ne coute pas cher
à mettre en place
La revue de sprint
Le sprint review

• Le but de la review est de montrer ce qui a été réalisé pendant le

sprint afin d’en tirer des enseignements et faire les adaptations
nécessaires pour la suite du projet
• Parmi les caractéristiques de cette réunion:
o La revue accueille plusieurs invités
o Toute l’équipe scrum participe à la réunion: l’équipe étendue avec le scrum
Master et le product owner
o Toutes les personnes qui sont parties prenantes du projet y sont invitées et
leur présence est vivement encouragée
o C’est la réunion à laquelle assiste le plus grand nombre de personnes
C’est l’occasion de faire collaborer tous les intervenants sur l’avenir du
produit
Le sprint review

• Durée de la réunion:
• La revue de sprint a lieu le dernier jour du sprint, elle sera suivie de la
rétrospective
• La durée de la réunion de revue de sprint est limitée à 4 heures max pour un
sprint de 4 semaines. Cette durée est à ajuster en fonction de la durée du
sprint en question - limiter à 1*n heures, ou n étant le nombre de semaines
dans le sprint
• La revue nécessite une préparation au moins pour accueillir le public et être
en capacité de leur faire la démonstration
• Le temps de préparation global ne devrait pas excéder une heure, car il n’y a
pas de présentation formelle à. Faire: pas de slides à préparer
Le sprint review

La revue montre le produit

o La revue de sprint porte sur le résultat de travail de l’équipe pendant le sprint:
le produit partiel potentiellement livrable: c’est cette version opérationnelle
qui est présentée
o Dans le cas d’un développement de logiciel, il a la même forme d’un build
incluant les stories finies, accompagnés de ce qui est nécessaire pour le faire
fonctionner (test, documentation, scripts,…) et déployé sur un environnement
de test
Résultats du sprint review

• Backlog du produit actualisé

o Le backlog du produit est mis à jour
o Les stories du sprint déclarées changent d’état et passent dans la zone du
backlog réservée aux stories finies
o Le feedback des participants à la démonstration peut entrainer la création de
nouvelles stories
• Eventuellement, plan de release et burnDown/BurnUp chart de
release mis à jour
o Le plan de release est impacté par les modifications sur le backlog et par la
mesure de la vélocité
o Le BurnDown ou BurnUp chart de release est complété avec un nouveau
point pour le sprint qui s’acheve, calculé à partir du backlog
En résumé

• La revue de sprint est l’occasion de faire partager les réalisations de

l’équipe avec le reste de l’organisation

• L’issue de la revue de sprint est un product backlog potentiellement

réorganisé de manière à ce que les PBI ayant le plus de valeur soient
probablement sélectionnés lors de la prochaine planification de sprint

• La visibilité apportée et le feedback reçu permettent d’augmenter les

chances que le produit soit un succès
La rétrospective de sprint
La rétrospective de sprint

• L’un des principes des méthodes agiles:

« A intervalles réguliers, l’équipe réfléchit à comment devenir plus efficace, puis
adapte et ajuste son comportement en conséquence »

• Cette réunion permet à l’équipe d’optimiser son autoévaluation en

effectuant une rétrospective du sprint:
o Faire ressortir les éléments qui ont bien fonctionné et ceux qui restent à
améliorer
o Des actions concrètes sont alors proposées pour le sprint suivant
Une pratique d’amélioration continue

• La rétrospective constitue un moment particulier ou l’équipe d’arrete de

produire, prend le temps de réfléchir et parle de ses expériences, avec l’objectif
de:
o Capitaliser sur les pratiques qui ont marché
o Éviter de refaire les mêmes erreurs
o Partager différents points de vue
o Permettre au processus de s’adapter aux nouvelles avancées dans la technologie utilisée pour
développer

• Elle dure trois heures au maximum (sprint d’un mois) apres la revue et avant de
clôturer le sprint
• La réunion est généralement animée par le scrum master
Une pratique d’amélioration continue

• Une rétrospective représente pour les participants une possibilité

d’apprendre comment s’améliorer
• L’idée est que ceux qui réalisent sont les mieux placés pour savoir
comment progresser
• L’objectif est l’apprentissage et non la recherche de fautes
• L’équipe est impliquée dans la mesure ou chacun doit:
o Comprendre le besoin d’amélioration
o Concevoir les améliorations
o S’approprier les améliorations
o Être motivé pour s’améliorer
Résultat de la rétrospective

• Le résultats actions de la rétrospective est la liste des actions qui ont

été décidées. On peut classer les actions selon leur orientations:
o Celles dirigées vers les personnes et leur façon d’appliquer les pratiques
o Celles orientées vers les outils à installer ou à adapter
o Celles axées sur l’amélioration de la qualité
• Par exemple, les actions impactant les personnes sont:
o Limiter scrum à 15minutes
o Faire une heure de travail en binôme tous les jours
o Modifier la façon de prendre en compte les bugs…
Exemple: la limitation des scrums quotidiens à 15minutes est l’amélioration
choisie par l’équipe
ü Les actions identifiées sont:
ü Apporter un minuteur
ü Annoncer le temps écoulé
ü Afficher la durée tous les jours
En résumé

• La rétrospective est la pratique SCRUM pour améliorer le processus

• Placée à la fin d’un sprint, la réunion implique toute l’équipe dans un

brainstorming en vue d’identifier des façons de mieux travailler

• Par rapport aux approches habituelles d’amélioration de processus.

Souvent imposées par la hiérarchie, elle donne la parole à l’équipe
pour qu’elle s’approprie la conduite de son processus