Le framework Scrum — Deuxième édition

Ce chapitre conserve le contexte historique et pratique des enseignements de la deuxième édition. Le programme de la troisième édition est également disponible dans le sommaire ci-dessous.

---

Les user stories Scrum : une présentation complète pour une gestion efficace

Définition : une user story Scrum décrit brièvement et du point de vue de l’utilisateur une fonctionnalité souhaitée dans un projet agile. Elle sert souvent à décrire les éléments du Product Backlog, mais Scrum n’impose pas ce format. Elle exprime qui souhaite quoi et pourquoi, tout en favorisant la collaboration et la communication pluridisciplinaires. Le modèle comprend un rôle d’utilisateur, ou acteur, une action ou un objectif et un avantage ou une valeur. Les user stories créent une compréhension commune des exigences, soutiennent la progression incrémentale et permettent de prioriser selon les besoins et les retours des utilisateurs.

Les user stories Scrum ressemblent à de petits scénarios de film pour chaque fonctionnalité du produit, plus courts et plus simples. Chaque histoire présente un personnage, l’utilisateur ou l’acteur, un objectif, la fonctionnalité voulue, et sa raison d’être, l’avantage apporté.Imaginez ces histoires réunies en un réseau de souhaits, d’attentes et de solutions : le backlog. Le gérer, le prioriser et l’affiner ressemble à la réalisation d’un film où chaque histoire est importante mais évolutive. L’International Scrum Institute vous accompagne pour maîtriser ces user stories et leur gestion.

Pour rédiger une user story claire et efficace, utilisez un format comme « En tant que [rôle], je veux [capacité] afin de [avantage] ». Par exemple : « En tant que client, je veux suivre facilement l’état de ma commande afin d’organiser mon emploi du temps en conséquence. »

Caractéristiques des user stories Scrum

Les éléments du Scrum Product Backlog sont souvent rédigés en user stories. Leur caractéristique essentielle est de raconter brièvement l’histoire d’une personne utilisant le produit. Elles comprennent un nom, un court récit et des critères et conditions d’acceptation pour être terminées. Leur avantage est de se concentrer exactement sur le besoin ou le souhait de l’utilisateur sans entrer dans les détails de la réalisation.

Il existe plusieurs recommandations pour définir les user stories. Voici un modèle possible :

En tant que [acteur], je [veux|dois] [action] afin de [résultat]
Ou une version plus courte :
En tant que [acteur], je [veux|dois] [résultat]

Acteur : La personne ou le persona dont la story décrit le besoin, et non la personne responsable du backlog. Il s’agit souvent d’un utilisateur, mais une formulation plus précise aide : « Administrateur », « Client connecté » ou « Visiteur non authentifié » rend l’histoire plus facile à comprendre et la situe dans son contexte.

Action : Ce que l’acteur souhaite faire. Une action obligatoire peut être précédée de « dois » ; sinon, on utilise « veux ».

Résultat : Ce que l’acteur souhaite obtenir en réalisant l’action. Il s’agit du résultat de cette action, vu de son point de vue.

User story Scrum : présentation

Dans la gestion de projet agile, les user stories sont essentielles pour communiquer efficacement les exigences des clients. Elles rendent concrètes des exigences abstraites en les présentant du point de vue de l’utilisateur final.

Ce sont des descriptions brèves et informelles de fonctionnalités, centrées sur les besoins clairs de l’utilisateur final, l’acteur de la story. Elles suivent souvent la forme « En tant que [utilisateur/acteur], je veux [fonctionnalité] afin de [avantage] ». Ce format simple et puissant précise qui utilisera la fonctionnalité, ce qu’il veut et pourquoi. Il donne ainsi une vue complète de l’exigence.

Supposons que les utilisateurs d’un site marchand aient besoin d’une recherche plus efficace pour trouver les produits. La story pourrait être : « En tant qu’acheteur, je veux une recherche plus efficace afin de trouver rapidement les produits qui m’intéressent. » Elle résume le besoin du point de vue de l’utilisateur et précise la valeur apportée.

Les user stories servent aussi de points de départ à des conversations détaillées entre parties prenantes, Product Owners et développeurs. Elles ouvrent des échanges utiles sur les besoins des clients et facilitent la collaboration et la compréhension commune.

Elles jouent également un rôle central dans les priorités du Product Backlog : elles aident à déterminer les fonctionnalités essentielles aux utilisateurs et celles à développer en premier.

Le rôle des user stories dans la gestion de projet agile

Comprendre les user stories aide beaucoup les équipes à cerner les besoins des clients. Cela leur permet de créer une valeur exceptionnelle en se concentrant sur les fonctionnalités qui comptent réellement pour les utilisateurs finaux.

C’est comme construire une maison : vous ne commenceriez pas sans plans ni compréhension des besoins du propriétaire. De même, les user stories posent les fondations et guident les développeurs pendant tout le projet en alignant les efforts sur les attentes des clients.

Vu leur importance dans les environnements agiles, les organisations doivent donner la priorité à l’apprentissage de user stories efficaces. L’International Scrum Institute propose des ressources complètes pour aider les équipes à maîtriser cet aspect fondamental. Elles expliquent comment affiner les stories et présentent les bonnes pratiques pour les gérer dans les Product Backlogs.

Maintenant que nous comprenons leur importance dans la gestion de projet agile, examinons l’art de rédiger des user stories efficaces et utiles.

Créer efficacement des user stories Scrum

Les user stories sont au cœur du développement agile, et bien les rédiger est essentiel à la réussite de tout projet. Voici les principes à garder à l’esprit.

Comprendre les besoins des utilisateurs

Comprendre les difficultés et les besoins des utilisateurs est la première étape essentielle. Prendre le temps de se mettre à leur place et de comprendre leurs expériences, leurs souhaits et leurs défis garantit que les stories répondent à de vrais besoins et apportent une valeur concrète. Enquêtes, entretiens et observations permettent de recueillir directement leurs avis.

Structurer les stories

SMART est un angle utile pour discuter du résultat attendu d’une story ; ce n’est pas un modèle obligatoire de Scrum :

• Spécifique - Définir ce qui doit être fait
• Mesurable - Déterminer comment mesurer la réussite
• Atteignable - Vérifier la faisabilité dans les contraintes données
• Pertinent - S’aligner sur les objectifs de l’entreprise et les besoins des utilisateurs
• Délimité dans le temps - Prévoir un calendrier de livraison clair

Cela donne un cadre clair aux développeurs et assure que chaque story contribue directement aux objectifs et apporte une réelle valeur aux utilisateurs.

Associer l’équipe

Associer toute l’équipe à la création des stories favorise la collaboration et une compréhension commune des exigences et des objectifs. Les points de vue des développeurs, concepteurs, testeurs et Product Owners donnent une vision globale du résultat attendu. Cette collaboration révèle tôt des enseignements et des difficultés et produit des stories affinées qui représentent mieux la vision collective.

Comprendre les utilisateurs avec empathie, structurer les stories et associer toute l’équipe : nous disposons maintenant des principes fondamentaux pour créer des user stories Scrum convaincantes et utiles.

Sur cette base, explorons les techniques de priorisation qui maximisent leur impact dans les projets agiles.

Techniques de priorisation des user stories

Quand le Product Backlog grandit, il devient indispensable de prioriser efficacement. Les fonctionnalités n’ont pas toutes la même importance ni le même effet sur la satisfaction client ou le produit. Voici deux techniques puissantes pour décider de manière éclairée et maximiser la valeur apportée par votre équipe agile.

La méthode MoSCoW

MoSCoW classe les user stories en quatre catégories : indispensables, importantes, souhaitables et exclues pour le moment. Cette démarche simple et efficace aide à repérer les fonctionnalités essentielles selon leur urgence et leur importance.

• Indispensables (Must Have) : Les fonctions non négociables, nécessaires au fonctionnement de base ou aux besoins fondamentaux des utilisateurs. Sans elles, la finalité principale du produit serait compromise.
• Importantes (Should Have) : Des fonctionnalités importantes, mais non critiques pour la première livraison. Elles complètent le produit et peuvent être reportées si nécessaire.
• Souhaitables (Could Have) : Des fonctionnalités désirables mais facultatives, qui améliorent l’expérience ou ajoutent de la valeur. Elles peuvent être différées sans affecter le fonctionnement essentiel.
• Exclues pour le moment (Won’t Have) : Des fonctionnalités jugées inutiles actuellement et volontairement écartées du périmètre de travail en cours.

Cette classification claire permet d’aligner les attentes des parties prenantes et de l’équipe agile et facilite un accord sur ce qu’il faut développer en premier.

Le modèle de Kano

En complément de MoSCoW, le modèle de Kano classe les user stories selon leur effet sur la satisfaction client. Il distingue trois catégories d’attributs : de base, de performance et d’enthousiasme.

• Attributs de base : Les exigences fondamentales attendues et souvent considérées comme acquises. Les satisfaire n’augmente pas forcément la satisfaction, mais leur absence peut entraîner de l’insatisfaction.
• Attributs de performance : Ils sont directement liés à la satisfaction : plus ils sont performants, plus celle-ci augmente. Le rendement décroissant s’applique toutefois ; des améliorations excessives ne renforcent pas toujours l’enthousiasme des clients.
• Attributs d’enthousiasme : Ils peuvent surprendre et ravir lorsqu’ils sont présents, mais leur absence influence peu la satisfaction.

En déterminant la catégorie de chaque story, le Product Owner comprend mieux les priorités et décide des fonctionnalités en fonction des besoins et des souhaits des utilisateurs.

Ces techniques aident l’équipe à apporter de la valeur par les fonctionnalités réellement importantes, à éviter les efforts inutiles sur les éléments secondaires et à améliorer la satisfaction globale.

Après ces techniques de priorisation, examinons le rôle essentiel des parties prenantes dans la conception et l’affinage des stories.

Le rôle des parties prenantes dans les user stories Scrum

Dans Scrum, les parties prenantes sont des étoiles qui nous guident. Elles connaissent les attentes des utilisateurs et les besoins de l’entreprise. Leurs contributions sont essentielles pour créer des stories qui reflètent réellement les exigences des deux. Sans elles, c’est comme conduire sans carte : on manque de direction et on risque de se perdre.

Imaginez le développement d’une application bancaire mobile. Les parties prenantes représentent le marketing, le service client, la sécurité informatique et plusieurs départements technologiques. Leurs perspectives forment une vue complète des besoins : le marketing peut privilégier une interface attrayante et intuitive, le service client des interactions fluides et la sécurité des protocoles robustes.

De même qu’il faut tout un village pour élever un enfant, il faut ces différents regards pour donner vie à une user story réussie.

Associer les parties prenantes à l’affinage aide de plusieurs façons :

• Pertinence concrète : Elles apportent des informations sur les situations réelles et les besoins, pour aligner les stories sur les exigences pratiques de l’entreprise.
• Boucle de retours : Leur participation active permet de recueillir des retours à chaque étape et de procéder à des améliorations itératives.
• Alignement sur les objectifs de l’entreprise : Elles rattachent les stories aux objectifs globaux et soutiennent des décisions plus stratégiques.

Sans leur contribution aux stories de notre application bancaire, nous pourrions créer des fonctionnalités qui ne répondent pas aux attentes ou aux exigences réglementaires. Il pourrait en résulter des retards ou des reprises coûteuses.

Les associer dès le départ développe leur sentiment de responsabilité et crée un environnement favorable à la collaboration et à la communication.

Leur rôle dans l’affinage des user stories Scrum est donc essentiel. Leurs enseignements et leurs conseils orientent les stories vers les objectifs métier et une réponse efficace aux besoins des utilisateurs.

Après ce rôle indispensable des parties prenantes, explorons l’estimation de la complexité pour une gestion Scrum efficace. (En savoir plus sur L’estimation de l’effort dans Scrum)

Estimer la complexité pour une gestion Scrum efficace

Dimensionner une user story aide à comprendre son effort et sa complexité. Les estimations soutiennent les décisions, sans constituer des garanties ; Scrum n’impose aucune technique particulière. Le Planning Poker est l’une des méthodes les plus courantes. Il utilise des cartes dont les nombres représentent différents niveaux d’effort ou de complexité.

Les membres discutent d’une story, puis choisissent individuellement leur carte. Tous la révèlent simultanément et discutent des écarts importants. Le processus se poursuit jusqu’à un consensus sur la complexité.

L’avis de chacun est ainsi pris en compte, ce qui encourage la participation. Les estimations partagées améliorent la compréhension mutuelle et peuvent révéler des complexités ou des difficultés jusque-là inaperçues.

Prenons une story de page de connexion : un membre pense que c’est simple et propose 3 ; un autre considère toutes les règles de validation et propose 8. En discutant ouvertement, l’équipe comprend mieux la tâche et repère parfois des composants oubliés.

Les estimations du Planning Poker servent au Sprint Planning, mais aussi à l’affectation des ressources et à la compréhension de la capacité. Le Product Owner s’en sert pour prioriser les stories selon leur complexité et leur valeur potentielle.

Ces estimations déterminent la quantité de travail réaliste d’un Sprint et évitent les engagements excessifs, l’épuisement ou les problèmes de qualité. Elles aident aussi à identifier les dépendances entre stories pour mieux ordonner et coordonner le travail.

L’estimation efficace de la complexité, notamment au Planning Poker, est fondamentale pour maintenir la transparence, favoriser la collaboration et décider de manière éclairée en gestion de projet Scrum.

Maintenant que nous comprenons cette influence, voyons comment les user stories soutiennent une gestion efficace du Product Backlog.

Utiliser les user stories Scrum pour gérer le Product Backlog

Les user stories portent la voix des clients et guident les développeurs vers des produits conformes aux besoins des utilisateurs. Leur contexte explique ce qui est attendu et la valeur apportée. Bien utilisées, elles clarifient les échanges et simplifient les décisions grâce à une compréhension complète des exigences, indispensable à un Product Backlog organisé et affiné.

Il est utile d’associer clients, utilisateurs finaux, Product Owners et développeurs à leur rédaction. Leurs perspectives diverses couvrent plusieurs exigences et cas d’utilisation et donnent une vision plus globale des fonctionnalités.

Dans une application bancaire, une story peut décrire le besoin de transférer facilement des fonds entre comptes. Elle aide à comprendre les fonctionnalités requises et leur effet potentiel sur l’expérience utilisateur.

Les user stories sont dynamiques : on peut les affiner et les reprioriser selon les besoins des clients et les tendances du marché. Leur réévaluation régulière maintient un Product Backlog agile et adaptable aux évolutions métier.

Chaque story doit être claire et précise sur sa fonctionnalité. Un format courant est : « En tant que (rôle), je veux (fonctionnalité) afin de (avantage). »

Ajouter des critères d’acceptation précise les conditions qu’une fonctionnalité doit respecter pour être considérée comme terminée. Ils mesurent objectivement si elle remplit son objectif et alignent développeurs et parties prenantes sur les résultats attendus.

Pour le transfert bancaire, un critère peut exiger de vérifier les identifiants des comptes et de générer rapidement les reçus. Toutes les parties partagent ainsi une même définition de la réussite de cette story.

Une bonne utilisation des stories aide les Product Owners à préciser les exigences et les développeurs à concevoir des solutions pertinentes. Leur affinage constant face aux évolutions métier crée un Product Backlog adaptable aux demandes du marché.

La polyvalence des user stories Scrum maintient le Product Backlog réactif aux besoins changeants des clients et au marché. Cette adaptabilité est essentielle pour livrer des produits qui correspondent réellement aux utilisateurs.

Quels sont les principaux composants d’une user story Scrum ?

Réponse : le rôle ou persona, une brève description de la fonctionnalité souhaitée et les critères d’acceptation. Ils éclairent le point de vue de l’utilisateur et guident le développement. Selon une enquête Stack Overflow de 2023, 87% des équipes agiles ont souligné l’importance de stories bien définies pour une gestion efficace du backlog.

Comment une user story contribue-t-elle au Sprint Planning et à la priorisation dans Scrum ?

Réponse : elles clarifient le point de vue, les besoins et les résultats attendus de l’utilisateur. L’équipe aligne ainsi ses efforts sur ses objectifs et décide des stories à traiter en premier selon leur valeur et leur complexité. Selon une enquête de VersionOne de 2022, les équipes qui priorisent efficacement pendant le Sprint Planning améliorent leur productivité et la satisfaction client.

Quel est l’objectif d’une user story dans Scrum ?

Réponse : elle exprime les exigences et les besoins des utilisateurs ou clients. Outil de communication entre développeurs et parties prenantes, elle améliore la compréhension et la collaboration. Elle vise la valeur client et aide à prioriser le backlog selon les retours et la valeur métier. Dans une enquête de la Scrum Alliance, 76% des répondants ont estimé que les stories avaient amélioré leur capacité à apporter de la valeur aux clients.

Comment rédiger des user stories efficaces pour le développement agile ?

Réponse : concentrez-vous sur les « trois C » : Carte, une description brève ; Conversation, la discussion des détails ; Confirmation, les critères d’acceptation. Gardez les stories courtes, précises et priorisées selon la valeur client. Selon VersionOne, 65% des équipes agiles estimaient que des stories petites et bien définies contribuaient à la réussite. La collaboration régulière entre développeurs, Product Owners et clients assure aussi une compréhension et un alignement communs.

Quelles sont les bonnes pratiques et les erreurs courantes dans l’utilisation des user stories Scrum ?

Réponse : définissez clairement rôle, objectif et avantage, priorisez selon la valeur et la complexité, associez toute l’équipe à la rédaction et à l’estimation et affinez régulièrement le backlog. Évitez les stories trop détaillées ou techniques, l’absence de parties prenantes, les stories trop grandes non décomposées et un backlog rarement actualisé. Selon une enquête de la Scrum Alliance, les équipes suivant ces pratiques ont rapporté une meilleure communication (74% des répondants), un meilleur alignement métier (68%) et une satisfaction client accrue (62%).

Récapitulatif des user stories Scrum

Le mapping attentif des exigences est essentiel : chaque story participe au développement itératif et décrit clairement un travail important. Souvent composants d’epics, les stories soutiennent la réussite d’une itération. Identifier les epics et les stories qu’ils regroupent assure une planification et une exécution complètes. Cet article a montré comment les stories améliorent la communication dans l’entreprise et la transmission d’informations utiles.

Elles apportent des avantages concrets aux développeurs et aux utilisateurs. Les exemples de cet article montrent comment elles facilitent des stratégies de test efficaces pour vérifier les critères de chaque livrable. Décomposer les fonctionnalités complexes en composants maîtrisables facilite le développement itératif. Cette démarche renforce la collaboration et permet de s’adapter aux exigences qui évoluent pendant chaque itération.

Les user stories sont ainsi un élément central des démarches agiles et donnent une structure à la gestion de projet. Décomposer un epic, planifier efficacement les itérations et améliorer la communication : elles jouent un rôle essentiel dans la réussite. Les exemples et les échanges sur les tests montrent leur valeur pour aligner chaque livrable sur les objectifs globaux. Pour approfondir les méthodes agiles, l’International Scrum Institute vous propose de vous inscrire à une certification Scrum et de développer l’expertise et la confiance nécessaires dans la gestion de projet.