• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 30/05/2023

Confirmez la maturité d'une User Story

Dans ce chapitre, je vais insister sur la distinction entre votre préparation et votre gestion de projet. Vous devez commencer par vérifier que le Product Backlog est bien exploitable. 🚀

La préparation des User Stories

Le Product Backlog doit être correctement défini avant le début de votre gestion de projet. Vous répondrez donc à deux impératifs essentiels lors de votre préparation :

  1. La collecte et l'étude des besoins du produit ou service.

  2. La définition d'un langage commun avec l'équipe.

Commencez par analyser les besoins exprimés par votre client et vos utilisateurs. Formalisez ensuite votre cadre de travail avec le modèle Scrum. Votre but est de lister avec l'équipe l'ensemble des fonctionnalités, en limitant d'abord au maximum votre niveau de précision.

La réussite du projet dépend aussi de votre capacité à coacher l'équipe Scrum. Vous apportez aux membres de l'équipe tous les moyens de travailler sans perturbation. Votre plus grande difficulté restera néanmoins d'anticiper la maturité des demandes entrantes et leur impact sur le sprint à venir. 🏁 Accompagnez le Product Owner en formalisant la définition du mot "prêt" :

  • Favorisez une bonne compréhension des besoins et des tâches.

  • Vérifiez la conformité des User Stories aux objectifs du projet.

  • Explicitez les critères d’acceptation pour chaque User Story.

  • Validez les compétences requises au sein de l’équipe Scrum.

  • Éliminez les dépendances externes de votre gestion de projet.

En suivant ces conseils, vous obtiendrez à coup sûr une bonne définition de "prêt" (DoR : Definition of Ready, en anglais). Vous pouvez ainsi garantir collectivement que les User Stories sont assez précises et matures pour candidater à un sprint. 

Je présente la définition de "terminé" dans le chapitre suivant.

L'optimisation des User Stories

Vous jugez une User Story avec la grille de critères INVEST. Elle vous aidera à reformuler un énoncé ou même à modifier en profondeur l'expression d'un besoin. Selon cet acronyme, une User Story est :

  • Indépendante.
    L'équipe est capable de développer la fonctionnalité avant ou après n'importe quelle autre. C'est un critère qui est plus facile à respecter avec des produits informatiques. Faites preuve d'imagination et d'abstraction afin d'encourager l'équipe à isoler les User Stories.

  • Négociable.
    Le Product Owner va essentiellement rédiger l'objectif fonctionnel de la User Story. C'est l'équipe qui discute ensuite des meilleures solutions pour développer le produit ou le service. Évitez les détails trop techniques afin de pouvoir rédiger collectivement les tâches à réaliser.

  • Verticale (valuable, en anglais).
    L'équipe doit incrémenter des fonctionnalités réellement utiles. C'est votre collecte des besoins du client et de l'utilisateur final qui oriente la formulation de toutes les User Stories. Découpez votre projet afin d'ajouter de la valeur au produit ou au service à l'issue de chaque sprint.

  • Évaluée (estimable, en anglais).
    L'équipe a une vision précise de la complexité que représente une User Story. C'est souvent une bonne formulation des critères d'acceptation qui facilitera cette estimation. Quantifiez collectivement l'effort avec le Planning Poker afin d'obtenir un consensus unanime.

  • Suffisamment petite (small, en anglais).
    L'équipe est en mesure de décrire jusqu'à deux jours de travail consécutifs. C'est un critère qui dépend surtout du nombre d'équipiers et de la durée du sprint. Planifiez entre une et cinq fonctionnalités par itération afin de livrer votre client fréquemment.

  • Testable.
    Le Scrum Master s'assure que la User Story est bien comprise, et que l'équipe peut fournir un exemple concret. C'est l'intégration de la fonctionnalité dans le produit ou le service que vous devez observer. Définissez en amont les tests de validation afin de garantir la qualité.

Les User Stories prêtes dans un tableau Kanban
Les User Stories prêtes dans un tableau Kanban

Je vous invite aussi à consulter mon cours Initiez-vous à la gestion de projet agile pour structurer les User Stories du Product Backlog dès votre première itération

En résumé

  •  Vous participez à la création d'un langage commun en aidant l'équipe Scrum à définir le mot "prêt" pour les User Stories et les tâches du projet.

  • En qualité de Scrum Master, vous vous assurez que les User Stories respectent bien la définition du “prêt”, et que tous les membres de l'équipe Scrum s'entendent bien sur le travail à faire pendant les sprints.

  • Inspectez les User Stories avec la grille de critères INVEST (et les tâches avec la grille de critères SMART).

Vous savez désormais préparer et optimiser des User Stories. 👉 Dans le chapitre suivant, vous allez apprendre à considérer en équipe qu'une tâche opérationnelle est bien terminée.

Exemple de certificat de réussite
Exemple de certificat de réussite