Apprenez à créer et à utiliser des user stories pour capturer les besoins des utilisateurs dans Scrum. Cette vidéo vous guidera à travers le processus de rédaction des user stories, de leur décomposition et de leur utilisation pour planifier les sprints.Nous partagerons des exemples et des conseils pour écrire des user stories claires et exploitables. En maîtrisant l'art des user stories, vous pourrez mieux comprendre et répondre aux besoins des utilisateurs.
La notion de base du Product
Backlog, c'est les Stories.
Donc on va parler des Stories et on va
décomposer chaque autre élément qu'on peut
intégrer dans le PB (Product
Backlog). Le Stories,
ce sont des descriptions simples d'un
besoin ou d'une attente, tout simplement.
Vous allez reformuler un besoin,
ou une attente de manière la plus
simple et la plus claire possible.
Une fois que ce travail est réalisé,
il faudra reformuler cette
Stories en User Stories.
Ça veut dire qu'on va la reformuler d'un
point de vue de l'utilisateur
ou du client.
Le but étant que les Users Stories
soient dites fonctionnelles.
Voici une idée de comment reformuler cela.
En tant que qui? Je souhaite quoi?
Afin de faire quoi?
Ou afin de
Pourquoi?
Voila un exemple de User Story.
Voilà un framework,
un cadre que vous pourrez utiliser
pour pouvoir formuler chacune
de vos User Stories. En tant que
qui?
Je voudrais quoi? Afin de pourquoi?
Récemment j'ai travaillé pour une entreprise
qui avait décidé de lancer,
bon ils décidaient encore s'il devait
acheter ou créer par eux-mêmes,
en tout cas, ils avaient décidé de lancer
un service d'intranet.
Donc un outil pour les salariés, les
collaborateurs pour être plus général.
Et dans les User Stories,
on a, entre autres, formulé un besoin.
C'est un exemple pour que vous compreniez
comment on pourrait le formuler d'un point
de vue concret. En tant que collaborateur,
en tant que salarié.
Je voudrais partager mon travail,
mes trouvailles avec mon équipe.
Afin de pouvoir
permettre à tout le monde d'être au même
niveau
lorsqu'on est en train de travailler sur
un projet. Voilà un exemple de User Story.
Dans les faits, ça veut dire quoi?
Une fois qu'on passera ça au Sprint
Planning, on découpera cela en tâches.
Ce sera donc la possibilité de créer
un contenu. D'écrire un article.
Pouvoir le publier.
Pouvoir Liker.
Supprimer.
On verra plus tard lorsqu'on fera le Sprint Planning
et qu'on va découper cela en tâches.
Mais déjà, en tant que User Story,
qui vit dans le Product Backlog,
l'idée, c'est ça : En tant
que qui? Je veux faire quoi?
Afin de pourquoi?
Une bonne story c'est...
Pour qu'elle soit une bonne Story,
il faut qu'il respecte quelques règles.
Et voilà un framework intéressant qu'on
appelle le framework INVEST ou le cadre
INVEST, ou la méthode
INVEST. Vous trouverez divers termes.
Je suis là pour vous expliquer tout.
Vous allez pouvoir donc s'assurer,
par rapport à ce cadre,
que votre Story est de qualité.
INVEST pour I N V E S T.
I pour Indépendant.
Ça veut dire que votre Story,
User Story doit être autonome
par rapport aux autres User Story.
N pour Négociable,
elle peut se négocier avec
l'utilisateur. V pour Valeur.
Elle est utile pour l'utilisateur.
E pour Estimable.
Il faut qu'on puisse l'estimer à divers
niveaux en termes
d'importances dans les Users Stories,
mais aussi plus tard dans le
Sprint Planning.
Je veux dire en terme de temps nécessaire
pour pouvoir réaliser cette
User Story avec l'équipe technique.
S pour Small,
elle, doit pouvoir se réaliser
au cours d'une seule itération.
Rappelez-vous, l'idée c'est qu'à la fin d'une d'itération, on
délivre un incrément opérationnel.
Vous User Stories doivent pouvoir vivre et être réalisées
durant une seule itération.
T pour testable.
Par rapport à des critères
d'acceptation, on va voir ce point juste
après. Il est très
très important ce point de critères
d'acceptation. Par rapport
à ces critères d'acceptation,
il faut qu'on puisse vérifier en pratique que
la User Story a été réalisée lorsqu'on voudra
tester et vérifier par la suite
que l'équipe de développement a bien fait
le travail. Pour pouvoir compléter
la définition des US et surtout
de comment on va bien créer une US.
Il faut absolument parler de cette
notion de critères d'acceptation.
Un critère d'acceptation,
c'est tout simplement une liste de points
qui permettront à l'utilisateur de confirmer
que la fonctionnalité, une fois livrée,
correspond effectivement aux attentes.
Là, vous commencez à comprendre le truc.
À la fin, je vous avais dit, si vous vous
en souvenez quand on avait vu le planning
ou le schéma basique d'un Sprint,
on n'avait vu qu'à la fin,
il y avait des réunions qu'on appelle
les Sprints Review et, plus tard,
la Rétrospective. Nous on va
s'intéresser ici à la Sprint Review.
C'est durant ce moment là qu'on avait
le client qui était invité et qui devait
tester ce qui a été réalisé. Pour tester ce
qui a été réalisé et savoir
si ça a été bien réalisé,
on va se baser sur les
critères d'acceptation ou
d'acceptabilité. S'ils répondent à ces
critères, on peut dire que la fonctionnalité a
été développée et a été implémentée
correctement. Donnons un exemple !
On est sur une US qui a pour but
de permettre à l'utilisateur de pouvoir faire
une recherche. Pour pouvoir vérifier si
cette fonctionnalité a été bien réalisée,
le critère d'acceptation, c'est quoi?
Ou les critères car il y en a 4 ici.
"Je peux rechercher par prénom
son nom de famille"
"Je peux rechercher par nom de famille sans le prénom"
"Je peux rechercher
par prénom et nom de famille"
"Je peux avoir
des relations proches,
si je fais une erreur en écrivant".
Grâce à ces critères-là, on sait si
la fonctionnalité a bien été implémentée ou pas.
Vous voyez l'idée?
C'est aussi pour ça qu'on
disait que les US étaient
formulées par l'utilisateur
et devaient être fonctionnelles.
Une question qu'on me pose régulièrement,
c'est combien de US peuvent vivre
dans un seul Sprint,
dans une seule itération? Alors, Bill Wake,
le fondateur et le créateur de la méthode
INVEST, indique que, en général,
il faudrait que 5 à 6 US puissent être
gérées dans un Sprint, dans une seule itération.
Backlog, c'est les Stories.
Donc on va parler des Stories et on va
décomposer chaque autre élément qu'on peut
intégrer dans le PB (Product
Backlog). Le Stories,
ce sont des descriptions simples d'un
besoin ou d'une attente, tout simplement.
Vous allez reformuler un besoin,
ou une attente de manière la plus
simple et la plus claire possible.
Une fois que ce travail est réalisé,
il faudra reformuler cette
Stories en User Stories.
Ça veut dire qu'on va la reformuler d'un
point de vue de l'utilisateur
ou du client.
Le but étant que les Users Stories
soient dites fonctionnelles.
Voici une idée de comment reformuler cela.
En tant que qui? Je souhaite quoi?
Afin de faire quoi?
Ou afin de
Pourquoi?
Voila un exemple de User Story.
Voilà un framework,
un cadre que vous pourrez utiliser
pour pouvoir formuler chacune
de vos User Stories. En tant que
qui?
Je voudrais quoi? Afin de pourquoi?
Récemment j'ai travaillé pour une entreprise
qui avait décidé de lancer,
bon ils décidaient encore s'il devait
acheter ou créer par eux-mêmes,
en tout cas, ils avaient décidé de lancer
un service d'intranet.
Donc un outil pour les salariés, les
collaborateurs pour être plus général.
Et dans les User Stories,
on a, entre autres, formulé un besoin.
C'est un exemple pour que vous compreniez
comment on pourrait le formuler d'un point
de vue concret. En tant que collaborateur,
en tant que salarié.
Je voudrais partager mon travail,
mes trouvailles avec mon équipe.
Afin de pouvoir
permettre à tout le monde d'être au même
niveau
lorsqu'on est en train de travailler sur
un projet. Voilà un exemple de User Story.
Dans les faits, ça veut dire quoi?
Une fois qu'on passera ça au Sprint
Planning, on découpera cela en tâches.
Ce sera donc la possibilité de créer
un contenu. D'écrire un article.
Pouvoir le publier.
Pouvoir Liker.
Supprimer.
On verra plus tard lorsqu'on fera le Sprint Planning
et qu'on va découper cela en tâches.
Mais déjà, en tant que User Story,
qui vit dans le Product Backlog,
l'idée, c'est ça : En tant
que qui? Je veux faire quoi?
Afin de pourquoi?
Une bonne story c'est...
Pour qu'elle soit une bonne Story,
il faut qu'il respecte quelques règles.
Et voilà un framework intéressant qu'on
appelle le framework INVEST ou le cadre
INVEST, ou la méthode
INVEST. Vous trouverez divers termes.
Je suis là pour vous expliquer tout.
Vous allez pouvoir donc s'assurer,
par rapport à ce cadre,
que votre Story est de qualité.
INVEST pour I N V E S T.
I pour Indépendant.
Ça veut dire que votre Story,
User Story doit être autonome
par rapport aux autres User Story.
N pour Négociable,
elle peut se négocier avec
l'utilisateur. V pour Valeur.
Elle est utile pour l'utilisateur.
E pour Estimable.
Il faut qu'on puisse l'estimer à divers
niveaux en termes
d'importances dans les Users Stories,
mais aussi plus tard dans le
Sprint Planning.
Je veux dire en terme de temps nécessaire
pour pouvoir réaliser cette
User Story avec l'équipe technique.
S pour Small,
elle, doit pouvoir se réaliser
au cours d'une seule itération.
Rappelez-vous, l'idée c'est qu'à la fin d'une d'itération, on
délivre un incrément opérationnel.
Vous User Stories doivent pouvoir vivre et être réalisées
durant une seule itération.
T pour testable.
Par rapport à des critères
d'acceptation, on va voir ce point juste
après. Il est très
très important ce point de critères
d'acceptation. Par rapport
à ces critères d'acceptation,
il faut qu'on puisse vérifier en pratique que
la User Story a été réalisée lorsqu'on voudra
tester et vérifier par la suite
que l'équipe de développement a bien fait
le travail. Pour pouvoir compléter
la définition des US et surtout
de comment on va bien créer une US.
Il faut absolument parler de cette
notion de critères d'acceptation.
Un critère d'acceptation,
c'est tout simplement une liste de points
qui permettront à l'utilisateur de confirmer
que la fonctionnalité, une fois livrée,
correspond effectivement aux attentes.
Là, vous commencez à comprendre le truc.
À la fin, je vous avais dit, si vous vous
en souvenez quand on avait vu le planning
ou le schéma basique d'un Sprint,
on n'avait vu qu'à la fin,
il y avait des réunions qu'on appelle
les Sprints Review et, plus tard,
la Rétrospective. Nous on va
s'intéresser ici à la Sprint Review.
C'est durant ce moment là qu'on avait
le client qui était invité et qui devait
tester ce qui a été réalisé. Pour tester ce
qui a été réalisé et savoir
si ça a été bien réalisé,
on va se baser sur les
critères d'acceptation ou
d'acceptabilité. S'ils répondent à ces
critères, on peut dire que la fonctionnalité a
été développée et a été implémentée
correctement. Donnons un exemple !
On est sur une US qui a pour but
de permettre à l'utilisateur de pouvoir faire
une recherche. Pour pouvoir vérifier si
cette fonctionnalité a été bien réalisée,
le critère d'acceptation, c'est quoi?
Ou les critères car il y en a 4 ici.
"Je peux rechercher par prénom
son nom de famille"
"Je peux rechercher par nom de famille sans le prénom"
"Je peux rechercher
par prénom et nom de famille"
"Je peux avoir
des relations proches,
si je fais une erreur en écrivant".
Grâce à ces critères-là, on sait si
la fonctionnalité a bien été implémentée ou pas.
Vous voyez l'idée?
C'est aussi pour ça qu'on
disait que les US étaient
formulées par l'utilisateur
et devaient être fonctionnelles.
Une question qu'on me pose régulièrement,
c'est combien de US peuvent vivre
dans un seul Sprint,
dans une seule itération? Alors, Bill Wake,
le fondateur et le créateur de la méthode
INVEST, indique que, en général,
il faudrait que 5 à 6 US puissent être
gérées dans un Sprint, dans une seule itération.
Partager :
5 KPI webmarketing à suivre pour piloter son marketing digital
Ce guide détaille cinq KPI essentiels pour piloter et rentabiliser sa stratégie webmarketing
Comment définir des objectifs SMART pour sa stratégie digitale ?
En 2025, de nombreuses petites entreprises françaises investissent dans le numérique mais sans objectifs précis, ce qui rend les actions difficiles à mesurer.
Pourquoi le Webmarketing est indispensable pour les TPE/PME en 2025 ?
On vous explique pourquoi le web est devenu un levier incontournable et comment il peut soutenir votre croissance, même sans budget conséquent
Leviers digitaux: lesquels prioriser pour votre entreprise en 2025 ?
Cet article vous aide à identifier les leviers marketing les plus adaptés selon la taille de votre entreprise (TPE, PME, freelance, artisan..).
Introduction aux Artefacts en Scrum
Les artefacts de Scrum structurent le processus de développement Agile.
Certification
Vue d'Ensemble des Outils de Gestion de Projets
Que vous soyez chef de projet expérimenté ou débutant, choisir les bons outils est une condition indispensable pour mener vos projets à bien.
Blockchain et IA : façonner l'avenir de l'innovation
Depuis l'avènement des nouvelles technologies, deux technologies ont créé des vagues : la Blockchain et l'intelligence artificielle (IA).
Comment la numérisation a contribué au succès de Starbucks Brew
Dans le monde compétitif d'aujourd'hui, tout le monde a du mal à savoir quelles nouvelles techniques peuvent les aider à prospérer.
"La formation PSM1 a été incroyablement utile pour améliorer mes compétences en matière de gestion de projet agile et devenir un Scrum Master certifiéJ'ai appris beaucoup de nouvelles techniques et de pratiques que je pourrais appliquer immédiatement sur mon lieu de travail."
"La formation PSM1 était intense, mais cela en valait vraiment la peineJ'ai été impressionné par la qualité des instructeurs et la quantité d'informations que j'ai apprises en peu de tempsJe suis maintenant plus confiant dans mes compétences de gestion de projet agile."
"Je recommande fortement la formation PSM1 à tous ceux qui cherchent à améliorer leurs compétences en matière de gestion de projet agileLes instructeurs étaient très compétents et ont su rendre le contenu facile à comprendre et à appliquer."
"La formation PSM1 a été une expérience incroyablement enrichissanteJ'ai appris à travailler plus efficacement en équipe et à utiliser les principes agiles pour livrer des projets de haute qualité à tempsJe me sens beaucoup plus confiant dans mon rôle de Scrum Master maintenant."
"Je suis ravi d'avoir suivi la formation PSMJ'ai appris à travailler en équipe de manière plus productive et à mettre en œuvre les principes agiles de manière efficaceJe recommande fortement cette formation à tous ceux qui cherchent à améliorer leurs compétences en matière de gestion de projet agile."
"La formation PSM1 était très interactive et pratique, ce qui a permis une meilleure compréhension des conceptsJ'ai appris à mettre en œuvre Scrum de manière efficace dans mon entreprise et à collaborer avec les membres de mon équipe de manière plus productive."
"La formation PSM1 était très bien structurée et les instructeurs étaient très compétentsJ'ai appris beaucoup de nouvelles techniques et de pratiques pour améliorer mes compétences de Scrum MasterJe recommande vivement cette formation à quiconque cherche à améliorer ses compétences en gestion de projet agile."
"La formation PSM1 a été une excellente occasion de renforcer mes connaissances en gestion de projet agileLes instructeurs ont fourni des exemples pratiques et des exercices qui m'ont permis de mieux comprendre comment appliquer Scrum dans mon travail quotidien."
"La formation PSM1 était très engageante et interactiveJ'ai appris à travailler en équipe de manière plus productive et à mettre en œuvre Scrum de manière efficaceJe recommande cette formation à tous ceux qui cherchent à améliorer leurs compétences en gestion de projet agile."
"La formation PSM1 a été une expérience incroyablement utile pour moi en tant que Scrum MasterJ'ai appris de nouvelles compétences et techniques pour mieux gérer les projets agiles, et j'ai pu appliquer ces connaissances dans mon travail quotidienJe recommande fortement cette formation à tous ceux qui cherchent à améliorer leurs compétences en gestion de projet agile."