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 SCRUM (SCRUM Team) 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
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
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
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
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 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
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.
Récap des user stories
Récap des user stories