Planifiez des versions à l’aide des cartes de User Stories
</p>
Créez votre carte de User Stories
La première étape consiste à ajouter les activités et tâches dans un ordre chronologique pour former l’ossature (backbone) de la carte.
Ensuite, ajoutez les User Stories issues de votre backlog produit. Placez chaque User Story verticalement sous la tâche qu’elle aide l’utilisateur à accomplir.
Planifiez les versions
Vous pouvez enrichir votre carte en y ajoutant les lots de User Stories qui composent une version, c’est-à-dire un ensemble de fonctionnalités pertinentes à livrer en même temps.
Pour utiliser votre carte de User Stories pour planifier les versions, adoptez le processus suivant en quatre étapes :
Priorisez les User Stories.
Créez des couloirs (swim lanes) pour chaque version.
Définissez un résultat cible pour chaque version.
Utilisez la planification des sprints (points d’histoire et vélocité) pour calculer les dates de livraison.
1. Priorisez les User Stories
La première étape consiste à prioriser les User Stories.
💡 Ne priorisez pas l’ossature (c’est-à-dire les Epics). Supposons que tous les éléments soient nécessaires. Concentrez-vous sur les User Stories pour que celles avec la priorité la plus élevée se trouvent en haut de la carte.
Vous pouvez le visualiser comme ceci
Vous vous demandez peut-être pourquoi vous devriez prioriser les User Stories (les tâches) et non les Epics (les activités) dans l’ossature ?
Le consultant Agile et auteur Jeff Patton explique ceci :
Lorsque vient le moment de planifier des versions, il n’est généralement pas important de prioriser les éléments de l’ossature entre eux.
💡 Exemple pour un site e-commerce :
L’ossature pourrait inclure les éléments suivants :
Page d’accueil
Page produit
Page de recherche
Panier
Page d’expédition
Page de paiement
Page de compte
Nous ne pouvons pas demander un ordre de priorité ici ; pour que le site fonctionne et que les utilisateurs puissent acheter des produits, nous avons besoin de tous ces éléments. Ces items sont essentiels et nécessaires pour livrer un Produit Minimum Viable (MVP). Cependant, il n’est pas nécessaire que chaque page dispose de toutes ses fonctionnalités dès le départ pour que le site soit opérationnel.
C’est précisément la raison pour laquelle vous priorisez les User Stories et non les Epics de l’ossature.
2. Créez des couloirs (swim lanes) pour chaque version
L’étape suivante consiste à planifier vos versions. La meilleure façon de procéder est de dessiner des lignes horizontales (vous pouvez utiliser du ruban adhésif !). Ces lignes créent des couloirs (swim lanes) pour chaque version.
💡 Déplacez les User Stories (de haut en bas) pour former des lots cohérents et importants à développer.
Dans le diagramme suivant, vous pouvez voir les couloirs (swim lanes) qui définissent les versions 1, 2 et 3.
Rappelez-vous qu’une version est un ensemble de fonctionnalités qui a du sens à livrer aux utilisateurs en même temps.
Exemple détaillé : Pour un site e-commerce, le client doit pouvoir trouver le produit, l’ajouter au panier, choisir une adresse de livraison et payer. (Certaines des User Stories dans cet exemple ne sont pas essentielles au bon fonctionnement du site, mais elles peuvent représenter un confort supplémentaire pour l’utilisateur.)
Le regroupement des versions pour la fonctionnalité "Acheter un produit" pourrait ressembler à ceci :
Dans la fonctionnalité "Acheter un produit", nous avons 3 Epics : Panier, Expédition et Paiement.
Nous avons créé trois couloirs. Le premier représente le MVP (Produit Minimum Viable). Il inclut les User Stories essentielles pour lancer le site e-commerce : voir les produits, choisir une adresse de livraison et payer par carte bancaire. Les User Stories des versions futures peuvent être priorisées au sein de chaque Epic en fonction de leur importance.
Dans l’exemple ci-dessus, plusieurs User Stories peuvent être livrées aux utilisateurs en même temps. Cependant, nous n’avons pas encore répondu à la question suivante : "Combien de temps faudra-t-il pour les livrer ?"
Cela ne signifie pas nécessairement que chaque version prendra le même temps à être développée. Ce regroupement des User Stories indique simplement quelles fonctionnalités doivent être livrées ensemble pour avoir du sens.
3. Définissez un résultat cible pour chaque version
Un résultat cible décrit ce que la livraison d’un lot de User Stories signifie pour les utilisateurs.
Exemple pour un déménagement :
Version 1 : Une fois les User Stories terminées, l’utilisateur peut déterminer le coût du déménagement.
Résultat cible : "L’utilisateur peut déterminer le coût du déménagement".
Version 2 : Une fois les User Stories terminées, l’utilisateur peut vérifier la disponibilité des services à une date donnée (par exemple, le samedi 15 mai).
Résultat cible : "L’utilisateur peut vérifier la disponibilité des services à la date choisie".
Le résultat cible est ensuite écrit sur une fiche ou un post-it, puis ajouté à la carte de User Stories.
4. Utilisez la planification des sprints pour calculer les dates de livraison
Comme vu dans un chapitre précédent, utilisez les estimations en points d’histoire et la vélocité pour déterminer le nombre de sprints nécessaires pour compléter toutes les User Stories d’une version. Allouez les User Stories aux sprints jusqu’à ce que le total des points atteigne la limite autorisée (c’est-à-dire la vélocité de votre équipe).
Cela produit un plan de version très visuel et basé sur des techniques d’estimation Agile.
La carte de User Stories vous fournit les informations suivantes :
La première date de livraison est après la fin du sprint trois (quelle que soit cette date).
La deuxième date de livraison est fixée après la fin du sprint cinq.
La troisième version peut être planifiée après la fin du sprint six.
Récapitulons !
Pour utiliser votre carte de User Stories dans la planification des versions, suivez le processus suivant en quatre étapes :
Priorisez les User Stories.
Créez des couloirs (swim lanes) pour chaque version.
Définissez un résultat cible pour chaque version.
Utilisez la planification des sprints (points d’histoire et vélocité) pour calculer les dates de livraison.
Si vous avez des estimations pour chaque User Story en points et que vous connaissez la vélocité de votre équipe, vous pouvez calculer les dates de livraison des versions représentées sur votre carte de User Stories.
Votre carte de User Stories peut également être utilisée pour communiquer des informations précieuses. Nous verrons comment faire cela dans le prochain chapitre !
