Petit guide pour Scrum Product Owner : Comment démarrer son product backlog partie 3/3


Dans les parties précédentes je vous ai présenté les étapes préliminaires à la création du product backlog.
Je vais maintenant vous parler des éléments du backlog à proprement dit, les « user Stories ».

Que sont les Les users stories ?
Ce sont les spécifications du projet présentées sous forme d’histoires utilisateurs qui décrivent les interactions de l’utilisateur avec le système de façon plus ou moins détaillées.

Comment se présente une user story ?
la partie principale est l’histoire elle même, je l’écris sous la forme suivante :
« En tant que ,
Je peux
Afin  »

Si on reprend notre ami Bob, on pourrait donc avoir une user story comme celle-ci :
« En tant que Bob,
Je peux Créer un compte client,
Afin de pouvoir leur louer des films »

ou bien

« En tant que Bob,
Je peux entrer une location,
Afin d’avoir une trace »

La rédaction d’une user story se doit de repondre au critères INVEST (independant, negotiable, valuable, estimable, small, testable)

  • Independant (indépendante) : Une user story se doit d’être indépendante de toutes les autres stories. En prenant cette définition à l’envers on la comprend mieux, une user story se doit de n’avoir aucune dépendance envers les autres stories, elle doit pouvoir être réalisée sans individuellement. Ce besoin découle du fait qu’à tout moment on veut pouvoir réorganiser, reprioriser le product Backlog. Si les stories ont des dépendances, cette repriorisation est limitée.
  • Negotiable (négociable): Toute story qui se trouve dans le backlog de produit, peut etre réécrite, repensée ou même supprimée à tout moment en raison de changements du marché, de modification de l’orientation de besoins techniques ou tout autre motifs valable provenant de membre de l’équipe ou des sponsors.
  • Valuable (valeur métier) : Toutes les stories se doivent de générer de la valeur pour l’utilisateur final. À cet effet, les stories techniques, bien que le fun à coder ou parfois nécessaires, n’apportent aucune valeur métier et ne devraient donc pas exister ou être incluses dans des stories régulières. On Essaiera donc de les limiter
  • Estimable : Une user story doit pouvoir être évaluée en terme de complexité par l’équipe. Si une user story ne peut être évaluée, elle ne sera jamais planifiée ni incluse dans un sprint backlog ou découpée en taches. Habituellement elle ne peut l’être lorsqu’elle manque d’informations de support, ou lorsque la description faite pas le Product Owner est insuffisante ou vague.
    Une catégorie particulière de story : Les epics ne peuvent être évaluée puisqu’elles représentent en fait un ensemble de stories, dans ce petit guide les Thèmes remplissent le même besoin. Vous pouvez toutefois les utiliser comme pense-bête.
  • Small (Petite ou de taille appropriée): Une user story doit être suffisamment petite pour permettre d’être évaluée avec le plus de précision et certitude possible. Si l’équipe évalue la complexité relativement élévée, cela démontre en général un niveau d’incertitude élevé et cela implique qu’elle devrait être découpée en plusieurs stories.
  • Testable : Garder en tête qu’une story ne peut être considérée finie sans qu’elle ait été testée avec succès. Si il n’est pas possible de tester la story due à un manque d’information, elle ne devrait surtout pas être considerée pour être incluse dans un sprint Backllog. Ceci est encore plus vrai pour les équipes intégrant les techniques XP et particulierement le TDD (développement piloté par les Tests).

Si une user story répond à tous ces critères sa place dans le product backlog est tout à fait justifiée. Il ne restera donc plus qu’a la prioriser.

En plus de l’histoire elle même, certaines informations utiles peut être ajoutées pour la définition de la story ce qui donnera comme ensemble :

  • Thème : Le théme auquel cette story est reliée. Utiliser un postit de la couleur définie dans le thème permet de rendre le backlog plus visuel.
  • Acteur : L’acteur ou personas utilisé pour rédiger la user story. La encore si c’est possible utiliser l’icone rend l’ensemble plus visuel
  • story : utilisée lorsqu’il s’agit d’une user story.
  • Description : utilisé lorsqu’il s’agit d’une story technique ou d’un bug
  • Valeur : La valeur métier, on pourra utiliser le même genre de principe que celui présenté pour les thèmes.
  • Complexité : Sera évaluée par l’équipe lors des sprint plannings ou des rencontre de travail du backlog produit (optionnelles)
  • ROI : le retour sur investissement se calcule simplement = Valeur/Complexité. C’est un indicateur intéressant pour prioriser le backlog.
  • Tests d’acceptation : permet de définir quels seraient les tests d’acceptation de la story.
  • Commentaires :
  • Apect itératif de la création et définition du product Backlog :
    Plus un élément du backlog est priorisé et donc proche d’être inclus dans un sprint plus il se doit d’être détaillé, estimable et petit.
    A contrario, tant qu’un élément du backlog est de faible priorité il nécessite moins de détail et peut rester plus vague. On va donc au fur et à mesure de la montée en priorité définir et decouper les stories en éléments plus clairs et plus petits.

    Donc, en basse priorité on pourrait retrouver « gerer les clients » qui rendu en pkus haute priorité sera decoupé en ajouter un client, modifier un client, supprimer un client …. ceci n est qu’un exemple.

    Pour l’aspect emmergence itérative, on pourra identifier les transactions centrales du système, comme dans notre exemple ce pourrait être l’écran de location de films dans lesquels tous les élements devraient être saisis manuellement, puis on creera la gestion de la bibliothèque de films et on en utilisera les données dans la location, puis la gestion des clients et on l’utilise dans les transactions de location.
    C’est ce que j’appelle un développement à itérations centrique autour des fonctionnalités majeures du système.

    Voila, j’espère que ceci vous éclaire un peu et vous permettra de vous préparer pour votre premier sprint planning.

    Advertisements

Petit guide pour Scrum Product Owner : Comment démarrer son product backlog partie 2/3


Lors de la première partie je vous ai présenté comment établir la vision du projet/produit et comment établir la liste des acteurs ou personas.
Je vais maintenant continuer à vous montrer comment créer ce product backlog.

Troisième étape : les thèmes ou regroupement de fonctionnalités
Si on a accordé aux deux premières étapes tout le temps et le soin necessaire, celle-ci sera facile à accomplir.
De la vision du produit on extraira facilement les thèmes principaux, ils forment l’objectif central du produit.
Notre vision était “
Offrir une solution de gestion de location vidéo complète, incluant suivi, facturation ainsi qu’un module de prélocation en ligne et d’analyse statistique pour les vidéoclubs
“, on en tire donc facilement les thèmes suivants :

  • location et suivi
  • statistiques
  • facturation
  • prélocation en ligne

À partir des définitions des personas on peut identifier d’autres thèmes.
Par exemple la définition de bob dit ” utiliser le système pour enregistrer les locations de vidéos, ainsi que les retours de location et Comme Bob utilise le système en présence de clients qui attendent, Bob veut que le système soit rapide et facile à utiliser, une ergonomie limitant les clicks sera désirée”
On peut donc extraire :

  • retour de location (en considerant que le suivi concerne les retards)
  • ergonomie simplifiée

De la définition de Caroline ” Caroline aura la responsabilité d’installer et de configurer et de supporter le système …”
On arrive facilement à :

  • installation du système
  • configuration du système

Pour chacun de ces thèmes, il va mantenant falloir préciser certains éléments :

  • Description : plus de détail concernant le thème, peut être même une liste de sous thèmes
  • Valeur commerciale : C’est un indicateur très important qui guidera vos choix et priorités
  • Critère de satisfaction : les critères qui feront de ce thème un succès
  • Couleur de post-it : permettra de facilement identifier les stories associées
  • Utilisateurs : la liste des utilisateurs que ce thème rejoint

Comment définir la valeur commerciale ?
J’utilise la méthode suivante afin de définir la valeur commerciale de chacun des thèmes :
1. Je compte le nombre de Thèmes que je possède, et je me donne 300 points par thème.
2. Pour chaque Thème j’accorde une valeur commerciale sur 1000 points.
3. Rapidement je remarque que je n’ai pas assez de point pour tout, cela m’oblige a différencier ce qui est vraiment une valeur ajoutée de ce qui l’est moins. J’utilise alors une évaluation comparative et je remarque rapidement 3 groupes. Les incontournables, les bons thèmes et ceux dont on pourrait se passer.

Cette valeur me permet de rapidement déterminer une priorité dans l’élaboration de mon projet.
Je réutiliserai cette valeur plus tard pour calculer un ROI par thème.

Exemple de thème

À la fin de cet exercice, la liste des thèmes obtenue est plus que satisfaisante et nous fournira la base de la création du backlog.

Quatrième étape: la vision de la première release
C’est le moment de commencer à prioriser sa vision et determiner ce qui serait une solution comportant suffisamment de valeur pour etre utile.
Dans notre exemple, une vision de la release initiale pourrait etre ” Offrir un système de location et de retour pour vidéoclub”.
Cette vision va permettre de prioriser les thèmes pour lesquels il faudra ecrire des user stories prochainement.
On comprend très bien que dans notre exemple, les thèmes statistiques ou prélocation en ligne ne feront pas partie de la release initiale, on pourra donc ne pas s’attarder dessus pour le moment.

Aprés cette étape on a des éléments de reponse pour la question Quelles seront les fonctionnalités à créer ? même si pour le moment il ne s’agit que de thèmes. On commence aussi à voir une idée de réponse pour Dans quel ordre devront-elles être livrées ?

Je vais maintenant décrire un processus de création des éléments du backlog dans la troisième partie …