Product Owners, business analysts et équipes produit · 2 jours (14 heures) · intra-entreprise, 10 participants maximum · Bordeaux ou à distance

Backlog et user stories : écrire ce que l'équipe peut réellement livrer

En bref

Durée: 2 jours (14 heures)
Format: Présentiel et distanciel
Effectif: 10 participants maximum
Niveau: Débutant
Public: Product Owners fraîchement nommés, à qui on a donné le rôle sans la formation
Prérequis: Aucun prérequis en méthodes agiles : le vocabulaire nécessaire est posé en début de session.
Méthodes: Un tiers d'apports, deux tiers d'atelier : le contenu théorique tient dans une demi-journée cumulée sur les deux jours.
Évaluation: Avant la session : questionnaire de positionnement en ligne (15 minutes) et envoi par chaque participant de trois à cinq éléments réels de son backlog, qui deviennent la matière des ateliers.
Délai d'accès: Planifié au cadrage, selon vos disponibilités
Tarif: Sur devis, selon le format, la durée et le nombre de participants. Le premier échange est gratuit.
Accessibilité et situation de handicap: Voir la rubrique dédiée

Tout le monde connaît le format « en tant que… je veux… afin de… ». Et pourtant, la majorité des backlogs que je reprends en mission sont remplis de lignes inexploitables : un rôle générique, un bénéfice qui reformule l'action, aucun critère d'acceptation, et une équipe qui devine. Ces deux jours ne portent pas sur la formule, ils portent sur ce qu'on met dedans. Les participants travaillent sur leur propre backlog, celui qu'ils rouvriront le lundi suivant, et en repartent avec une tranche affinée, découpée et priorisée, prête à entrer en sprint.

Objectifs pédagogiques

Distinguer, dans une demande entrante, le besoin réel de la solution déjà arbitrée par le demandeur
Rédiger une user story qui répond aux trois questions pour qui, quoi et surtout pourquoi
Formuler des critères d'acceptation vérifiables, directement transformables en cas de recette
Relire une story avec la grille INVEST et décider, critère par critère, de la garder ou de la réécrire
Découper une story trop grosse en tranches livrables sans perdre la valeur utilisateur
Prioriser un backlog avec MoSCoW et RICE, et justifier un refus devant le demandeur
Animer une séance d'affinage qui produit un lot de stories prêtes à développer

Programme

01À quoi sert un backlog, et pourquoi le vôtre ne sert plus à ça

Jour 1 · 1 h 30

Projet et produit : un projet a une fin et se mesure à la livraison conforme, un produit évolue tant qu'il a des utilisateurs et se mesure à la valeur créée
Ce qu'un backlog doit permettre de décider, et ce qu'il n'est pas : ni un fourre-tout de demandes, ni un compte rendu de réunion
Le piège du Product Owner qui ne peut pas dire non : sans pouvoir d'arbitrage, le rôle se dégrade en secrétariat de backlog
Diagnostic à chaud : chaque participant ouvre son backlog et compte les lignes qu'une équipe pourrait développer sans poser de question

02Écrire une story qui révèle le besoin

Jour 1 · 2 h

Le format « en tant que [rôle], je veux [action], afin de [bénéfice] » : son seul intérêt est de forcer trois réponses, pour qui, quoi, et surtout pourquoi
L'exemple avant/après commenté : « ajouter un bouton export » contre une story qui nomme le rôle, le format attendu et l'usage aval
Comment une bonne story révèle que le vrai besoin est ailleurs que dans la solution demandée
Les quatre erreurs qui reviennent : la solution technique déguisée en valeur utilisateur, le « afin de » qui reformule l'action, la story-fleuve, le rôle générique « en tant qu'utilisateur »
Atelier : réécriture de trois éléments du backlog de chaque participant, puis lecture croisée

03Les critères d'acceptation, la partie qu'on saute

Jour 1 · 2 h

Pourquoi une story sans critères d'acceptation n'est pas prête à développer : ce sont eux, et non l'estimation, qui définissent « terminé »
Écrire un critère précis, vérifiable et testable : périmètre des données, format attendu, cas limite, comportement quand il n'y a aucun résultat, exigence de performance
Du critère au cas de recette : chaque critère bien écrit devient un scénario exécutable par un testeur qui n'a pas assisté aux ateliers
Le nombre juste de critères : quand on en écrit quinze, c'est en général la story qu'il faut découper
Atelier : production d'un jeu complet de critères sur deux stories réécrites au module précédent, relecture par un binôme jouant le testeur

04Se relire avec INVEST

Jour 1 · 1 h 30

La grille INVEST comme outil de relecture, pas comme dogme : indépendante, négociable, valorisable, estimable, suffisamment petite, testable
Ce que chaque critère détecte concrètement dans un backlog réel, et lequel est le plus souvent en échec
La règle de décision : deux critères en échec ou plus, la story est à réécrire avant d'entrer en sprint
Atelier noté : six stories à qualifier, corriger et justifier, correction commentée en groupe

05Découper sans perdre la valeur

Jour 2 · 2 h

Repérer une story trop grosse : elle contient « et », « ou », trois écrans, ou l'équipe ne sait pas l'estimer sans deviner
Les axes de découpage utilisables sur un backlog métier : par étape du parcours, par règle de gestion, par type de donnée, par variante d'utilisateur, par cas nominal puis cas limites
Le découpage à ne pas faire : par couche technique, qui produit des tranches invérifiables par un utilisateur
Vérifier après découpage que chaque tranche reste livrable et démontrable seule
Atelier : découpage de la plus grosse story apportée par chaque participant, puis démonstration au groupe que la première tranche a une valeur autonome

06Prioriser, et assumer les refus

Jour 2 · 2 h

Pourquoi une priorisation qui ne refuse rien n'est pas une priorisation : si tout est prioritaire, c'est l'équipe qui arbitre à votre place, en silence
MoSCoW : poser les must, should, could et won't sur un périmètre daté, et tenir la colonne won't
RICE : portée, impact, confiance, effort — ce que le score sert à objectiver et ce qu'il ne remplace pas
Formuler un refus devant un demandeur : nommer l'arbitrage, la contrepartie et la condition de réexamen
Atelier : priorisation collective du backlog consolidé des participants, puis mise en situation de refus face à un demandeur joué par le formateur

07L'affinage comme rituel, pas comme corvée

Jour 2 · 1 h 30

Placer l'affinage dans la cadence de l'équipe : fréquence, durée, participants, matière à préparer en amont
Ce qu'une séance d'affinage doit produire : un lot de stories que l'équipe accepte de planifier sans réserve
Les conditions pour qu'une story entre en sprint planning : bénéfice explicite, critères écrits, taille tenable, dépendances identifiées
Tenir la qualité du backlog dans la durée : que faire des vieilles lignes que personne ne rouvre
Atelier : construction de la trame d'affinage de votre équipe, avec ordre du jour et sortie attendue

08Mise en situation finale et plan des trente premiers jours

Jour 2 · 1 h 30

Mise en situation évaluée : produire une tranche de backlog de trois à cinq stories affinées, critères compris, et la défendre devant le groupe qui joue l'équipe de développement
Quiz de validation des acquis, corrigé et commenté
Plan d'application individuel : ce que chaque participant change dans son backlog dès la semaine suivante, en trois actions datées
Cadrage du point de suivi à distance et des sujets à y remonter

Public concerné

Product Owners fraîchement nommés, à qui on a donné le rôle sans la formation
Business analysts en transition vers un rôle produit
Équipes produit de startups et de PME qui écrivent leurs stories à plusieurs
Chefs de projet qui héritent d'un backlog existant et doivent le remettre d'aplomb
Développeurs et testeurs qui reçoivent ces stories et veulent peser sur leur qualité

Ce que les participants emportent

Une trame de user story et une trame de critères d'acceptation, au format de votre outil de suivi
La grille INVEST sous forme de checklist de relecture, utilisable seul en trois minutes par story
Le catalogue des axes de découpage vus en session, avec un exemple traité pour chacun
Une grille MoSCoW et une feuille de calcul RICE préremplie avec vos propres critères
Une trame de séance d'affinage : ordre du jour, durée, rôles, sortie attendue
La tranche de backlog produite pendant les deux jours, directement réutilisable en sprint
Les exemples avant/après issus de vos propres éléments, conservés par l'entreprise
Un plan d'application individuel en trois actions datées

Prérequis

Aucun prérequis en méthodes agiles : le vocabulaire nécessaire est posé en début de session.
Travailler avec une équipe de développement, ou être sur le point de le faire.
Apporter un backlog réel, ou à défaut une liste de demandes en cours : les ateliers portent sur vos propres éléments. Un backlog fil rouge est fourni aux participants qui n'en ont pas encore.
Un ordinateur avec accès à votre outil de suivi (Jira, Azure DevOps, Notion, Trello, ou un simple tableur).

Méthodes pédagogiques

Un tiers d'apports, deux tiers d'atelier : le contenu théorique tient dans une demi-journée cumulée sur les deux jours.
Travail sur le backlog réel de l'entreprise, apporté par les participants et anonymisé si nécessaire.
Exemples avant/après commentés collectivement, tirés de backlogs de missions et rendus anonymes.
Relecture croisée systématique en binômes : on écrit, puis on fait tester ce qu'on a écrit par quelqu'un qui n'était pas dans sa tête.
Mises en situation jouées : le testeur qui reçoit la story, le demandeur à qui l'on oppose un refus.
Un backlog fil rouge complet pour les participants dont les éléments ne sont pas exploitables en session.
Restitution collective et décisions écrites à la fin de chaque atelier.

Évaluation des acquis

Avant la session : questionnaire de positionnement en ligne (15 minutes) et envoi par chaque participant de trois à cinq éléments réels de son backlog, qui deviennent la matière des ateliers.
Pendant la session : chaque atelier produit un livrable écrit, relu en binôme puis repris en collectif — story réécrite, jeu de critères d'acceptation, découpage, backlog priorisé.
Fin du jour 1 : exercice de relecture évalué — six stories à qualifier avec la grille INVEST, à corriger et à justifier, correction commentée en groupe.
Fin de session : mise en situation finale évaluée sur une grille remise dès l'ouverture — produire une tranche de backlog de trois à cinq stories affinées, critères d'acceptation compris, et la défendre dix minutes devant le groupe.
Quiz de validation de vingt questions (format, critères, INVEST, découpage, priorisation), corrigé et commenté avant la clôture.
Quatre à six semaines après : point à distance de 45 minutes pour mesurer ce qui a effectivement été appliqué au backlog et lever les blocages rencontrés en conditions réelles.

D'où vient ce que j'enseigne

Adrien Bouthet, Chef de Projet IT et Product Owner freelance à Bordeaux, indépendant depuis mars 2019. Ce que j'enseigne dans ces deux jours vient de backlogs que je tiens en mission, pas d'un support générique. Depuis février 2025, je conçois et j'alimente le backlog Jira des parcours d'entrée en relation de La Banque Postale — ouverture de compte, parcours majeur et mineur, souscription du Livret A — avec les équipes métiers, techniques et partenaires, sur un budget projet de l'ordre du million d'euros et sous contrainte KYC et RGPD. C'est dans ce type de contexte qu'on apprend ce que vaut un critère d'acceptation : il devient un scénario de recette, et le parcours passe ou ne passe pas en production. Product Owner chez Ctrl Up en 2023, j'ai dirigé le développement en agilité Scrum et accompagné les développeurs directement chez les clients. Chez EDF, entre 2020 et 2022, j'ai piloté un portefeuille de projets IT et IoT industriel comprenant une application de gestion de la demande qui absorbe environ 20 000 tickets par an, avec des équipes de 2 à 10 personnes. J'interviens par ailleurs comme formateur auprès d'écoles bordelaises depuis 2020 (EPSI, Ynov, WIS, Infosup, Nexa), et les supports de cette session reprennent l'exemple avant/après, les critères d'acceptation testables et la grille INVEST que je publie sur ce site.

Cas concret

Exemple concret : sur les parcours d'entrée en relation de La Banque Postale, la conception et l'alimentation du backlog Jira avec les équipes métiers, techniques et partenaires ont accompagné l'intégration de 2 partenariats externes et une production tenue à moins de 3 incidents par an. Les critères d'acceptation y deviennent directement les scénarios de recette : c'est cette exigence-là que les ateliers de la session reproduisent, sur vos propres éléments.

Lire l'étude de cas

Questions fréquentes

Deux jours pour des user stories, ce n'est pas beaucoup ?+

Le format d'une user story s'explique en dix minutes, et c'est exactement pour cela que les demi-journées sur le sujet ne changent rien. Le jour 1 est consacré à ce qui fait la différence, la recherche du besoin réel et l'écriture de critères d'acceptation testables ; le jour 2 au découpage, à la priorisation et à l'affinage, c'est-à-dire à tenir le backlog dans la durée. Les deux tiers du temps sont des ateliers sur vos propres éléments, pas des exposés.

Nos stories sont écrites par le métier et par les développeurs, pas par un Product Owner. Est-ce que ça vaut quand même ?+

Oui, et le format intra-entreprise est même fait pour ça. Quand la rédaction est partagée entre plusieurs personnes, l'enjeu n'est pas la compétence individuelle mais la convention commune : quelles questions on se pose avant d'écrire, ce qu'on appelle « terminé », qui tranche quand deux demandes se contredisent. Mélanger métier, produit et développement dans la même session est souvent le vrai bénéfice, parce que la convention se décide dans la salle.

Faut-il utiliser Jira ?+

Non. Le contenu est indépendant de l'outil : Jira, Azure DevOps, Notion, Trello ou un tableur, on travaille dans le vôtre. Les trames remises sont adaptées à votre format de ticket pendant la session, pour qu'elles soient utilisables telles quelles le lundi suivant.

Faut-il pratiquer Scrum pour suivre cette session ?+

Non. Un backlog utile, des critères d'acceptation testables et une priorisation assumée servent autant en flux continu ou en Kanban qu'en sprints. Les modules sur l'affinage et l'entrée en planification sont adaptés à votre cadence réelle, quelle qu'elle soit.

En quoi est-ce différent de la formation Agile et pilotage de projet ?+

La formation Agile et pilotage de projet couvre le cadre complet : rituels, tableaux de bord, pilotage par les objectifs, pour des dirigeants et des équipes qui démarrent. Cette session descend d'un cran et reste sur un seul objet, le backlog et ce qu'on y écrit. Les deux se complètent, elles ne se remplacent pas : on peut suivre celle-ci sans avoir suivi l'autre.

Notre backlog est confidentiel. Comment fait-on ?+

Les ateliers se déroulent dans vos locaux ou dans votre environnement, sur vos propres outils, et rien n'est extrait de votre système d'information. Les éléments envoyés en amont peuvent être anonymisés par vos soins, et un accord de confidentialité est signé avant la session si votre politique interne l'exige.

Combien de participants au maximum ?+

Dix. Au-delà, la relecture croisée et la mise en situation finale ne tiennent plus dans le temps imparti, et la session redevient un exposé. Pour un effectif supérieur, on organise deux sessions plutôt qu'un grand groupe.

La session peut-elle se dérouler à distance ?+

Oui, en visio, avec le même déroulé et les mêmes ateliers en sous-groupes. Le présentiel reste préférable pour le jour 2, où la priorisation et les mises en situation de refus gagnent à se jouer dans la même pièce. Le format mixte est courant : jour 1 à distance, jour 2 sur site à Bordeaux ou chez vous.

Cadre et conditions

Financement

Ces sessions sont facturées directement à l'entreprise, sur son budget propre de développement des compétences. Elles ne sont pas éligibles aux financements mutualisés (OPCO, CPF, France Travail), qui supposent une certification Qualiopi.

Certification

Cette session n'est pas certifiante. Je ne délivre aucune certification Scrum.org, Scrum Alliance, Scaled Agile (SAFe) ou PeopleCert (ITIL), ni aucun titre enregistré au RNCP ou au Répertoire spécifique. L'objectif est opérationnel : des pratiques applicables, pas un diplôme.

Cadre contractuel

Chaque session donne lieu à une convention de formation professionnelle signée avant le démarrage, précisant les objectifs, le programme, la durée, les modalités de déroulement et le tarif convenu. Le règlement intérieur applicable à la session est remis aux participants à l'ouverture.

Attestation

Une attestation de fin de formation est remise à chaque participant à l'issue de la session. Elle mentionne les objectifs, la nature et la durée de la formation, ainsi que les résultats de l'évaluation des acquis.

Accessibilité et situation de handicap

Référent handicap : Adrien Bouthet, contact@adrienbouthet.fr. Toute situation nécessitant un aménagement (accès aux locaux, adaptation des supports, du rythme ou des modalités d'évaluation) est étudiée lors du cadrage, sous 5 jours ouvrés. Si l'aménagement dépasse nos moyens, nous orientons vers les ressources spécialisées (Agefiph, Cap emploi).

Un backlog à remettre d'aplomb

Réservez un premier échange gratuit. On regarde l'état réel de votre backlog, le nombre de participants et vos contraintes de calendrier, et je vous propose un déroulé construit sur vos propres éléments.

Réserver un échange gratuit Me contacter

L'offre correspondante

Product Owner freelance

Voir tout le catalogue