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.

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 …

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


Lorsqu’une entreprise décide d’implanter l’agilité et plus précisément Scrum, le product owner nouvellement formé comprend que la responsabilité qui lui incombe maintenant représente tout un défi.

Il doit créer le product backlog initial et ensuite le maintenir, cet artefact sera l’essence du projet.
Mais par où commencer ?

les étapes de l’élaboration du product backlog que je vous présente ici permettront de répondre aux 3 questions suivantes :

  • Quelles seront les fonctionnalités à créer ?
  • Dans quel ordre devront-elles être livrées ?
  • À qui sont elles destinées ?

Au cours de ce guide nous retrouverons ces questions et leurs réponses.

Je me propose de montrer, pas à pas ce que doit construire le Product owner avant le premier Sprint planning d’un projet pour un nouveau produit. Je vais aussi présenter ma compréhension de projets itératifs qui émergent durant le processus Scrum.

Bien qu’il soit recommandé de faire ce travail en équipe, idéalement une équipe composée de gens du marketing, de gens de métier et de stakeholders (sponsors), fréquemment le Product owner fera le travail seul. Si il est issu du marketing les premières étapes ne devraient pas poser de problèmes particuliers.

Lorsque le travail est effectué en équipe, il n’est pas toujours évident de partir les séances de brainstorming. Dans l’article je présente une solution permettant d’éviter le syndrome de la page blanche lors de travail collaboratif. Cette même technique peut être appliquée à toutes les étapes de la création du backlog.
L’important à retenir de cette technique, est qu’il faut définir des délais suffisamment longs (sans exagérer) pour permettre de passer outre les réponses évidentes.

Avant de commencer, je propose de prendre un exemple simple : un système de gestion des locations vidéos.

Première étape : établir la vision du projet.
Il s’agit en quelques lignes de définir quel est l’objectif que le projet devra atteindre avant que le Product Owner n’en arrête le développement.
Il est important que cette vision soit acceptée et comprise de tous, elle doit faire consensus puisque l’équipe va devoir se rallier derrière le PO pour réaliser ce projet selon cet objectif.

Offrir une solution de gestion complète, incluant suivi, statistiques et facturation ainsi qu’un module de prélocation en ligne et d’analyse statistique pour les vidéoclubs
Bien que cela puisse paraitre simple il n’est pas évident d’obtenir de la part des sponsors l’information permettant l’élaboration de cette vision, cela nécessitera bien des rencontres.

Deuxième étape : lister les acteurs / personas.
Il va falloir identifier puis détailler tous les intervenants, utilisateurs du système dans tous ses aspects.
Pour chaque intervenant on voudra préciser les informations suivantes :

  • Surnom : donner un Surnom aux acteurs rendra plus agréable leur utilisation et il sera plus simple de s’y identifier.
  • icone / image : ajouter une représentation graphique de l’acteur rend l’identification encore plus facile.
  • rôle : c’est en fait une description courte souvent juste un mot ou nom commun
  • description : on décrit pourquoi et/ou comment cet acteur utilisera le système
  • critères de satisfaction : ce qui rendra cet acteur satisfait de l’utilisation qu’il fait du système
  • valeur commerciale : élevée, moyenne, basse, bloquante (les autres acteurs ne pourront utiliser le système)
  • fréquence d’utilisation : permanente, quotidienne, occasionnelle, rare
  • nombre d’instances : combien d’intervenants comme celui-ci utiliseront le système. 1, 10, 100+
  • niveau de connaissance technologique : élevée, moyenne, basse
  • niveau de connaissance métier : élevée, moyenne, basse

Je réaliserai seulement deux exemples ici :

  • Bob
  • une image de bonhomme
  • Commis à la location de vidéo
  • Bob utiliser le système pour enregistrer les locations de vidéos, ainsi que les retours de location
  • 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
  • Élevée
  • Permanente
  • 10 par installation
  • Moyenne (souvent des jeunes à ce poste)
  • Élevée

Exemple de personas.

  • Caroline
  • une image de femme
  • Administratrice systéme
  • Caroline aura la responsabilité d’installer et de configurer et de supporter le système au niveau technique
  • Caroline désire une installation sans soucis, une configuration souple et simple à la fois et avant tout un logiciel fiable libre de crash
  • Bloquante
  • Rare
  • 1 par installation
  • Élevée
  • Basse

En créant les personas nous créons les éléments de réponse à la troisième question : À qui sont elles destinées ?

Dans la prochaine partie je vous parlerai des Thèmes/fonctionnalités et de la vision de release.

Comment le Scrum Product Owner peut définir la date d’une livraison(release) d’un nouveau produit ?


Lors de la création d’un nouveau produit, en tant que Product owner, la question qui revient tout le temps de la part des stakeholders (sponsors) est la suivante:
Quand est-ce que l’on release, quand est-ce que le produit sera prêt ?

Habitués par les projets waterfall, les sponsors s’attendent à une date de livraison incluant tout ce qu’ils peuvent avoir en tête que cela soit ou non dans les dossiers de spécifications.
Ils ont aussi en tête les nombreux dépassements de date, et les désaccords sur ce qui sera livré.

Alors, en tant que Product Owner, quelle date doit on leur donner et quelles clarifications devront nous faire ?

La première chose que nous devons expliquer est qu’il s’agira d’un livraison initiale, qu’en aucun cas nous attendrons que le produit soit « terminé » pour livrer.
Cette livraison initiale proposera un set de fonctionnalités suffisant pour permettre l’évaluation de la livraison et l’orientation du développement futur.
Pour ce qui concerne la date de cette livraison initiale, en fait nous avons deux choix : Une livraison à date fixée ou une livraison à périmetre fixé.
Ces deux options ne peuvent être combinées, sinon on revient au waterfall…

Voyons ces deux options en détail :

La livraison à périmètre fixé :
Le perimetre est un ensemble de fonctionnalités sur lequel le product owner et le sponsor s’entendent pour les définir comme etant le contenu de cette première livraison, la date de livraison ne peut donc être fixée.
Dans cette option le PO doit tout faire pour, avec le sponsor, déterminer un périmètre initial raisonnable, et non pas un périmètre gigantesque qui va repousser la première release trop loin et nous replacer dans une situation waterfall.
C’est le périmetre qui définit le moment de la livraison, elle dépendra donc de l’ampleur du périmetre et de la capacité de l’équipe.
Au fil de l’avancement du développement deux éléments se précisent :

  • le backlog de produit devient de plus en plus complet permettant ainsi de connaitre l’effort qu’il reste à fournir
  • La vélocité moyenne de l’équipe se raffine ( à condition de ne pas porter de changements à l’équipe)

Avec ces deux informations le Product Owner va être de plus en plus en mesure d’estimer un intervalle de sprints restants et donc la période de livraison.

Attention : Cette livraison ne doit pas forcement aller sur le marché, elle peut servir pour des beta testeurs.

La livraison à date fixée :
Le sponsor établit la date à laquelle il désire que la livraison initiale intervienne, ce sont souvent des contraintes soient opérationnelles soient marketing qui dictent cette date.
Le Product Owner aura alors pour objectif de maximiser la valeur livrée à cette date.
Évidemment le bon sens doit être de mise, cette livraison initiale comporte forcement un périmètre minimum, sans lequel la valeur livrée sera insuffisante.
C’est le rôle du product owner de faire comprendre ceci et de s’assurer que cette date fixée assure d’atteindre ce périmètre minimal.
Il est important que la première livraison soit relativement rapide étant donné qu’elle apporte la valeur initiale, permet le feedback des sponsors et des premiers utilisateurs, et peut même permettre le début du ROI en étant commercialiser.

Laquelle des deux options choisir ?
Je préfère de loin une livraison a date fixée, dans ce type de gestion le product owner aura une grande responsabilité : celle de maximiser la valeur. Dans l’autre option aussi mais les fonctionnalités à developper son beaucoup plus clairement établies.
Aussi la gestion par périmètre, n’ayant pas de date fixe, elle a de plus grands risques de laisser place à du développement superflu.
À l’opposé une livraison à date fixe oblige toute l’équipe à s’en tenir à ce qui minimalement repond au besoin story apres story et génère un produit pkus « lean ».

Selon moi, les livraisons par périmètre ne devraient avoir lieu que lorsque ce perimetre est dicté par des inmperatifs technologiques. Par exemple un produit qui s’appuie sur plusieurs éléments interdépendants et que si un seul de ces éléments est manquant, tout le produit est non fonctionnel. La valeur livrée reste nulle tant que le périmetre n’est pas atteind.

Dans le cas d’un produit destiné à la revente, la date fixe est l’option la plus recommandée puisqu’elle permet de synchroniser le plan marketing, la formation des vendeurs et la préparation du support technique. La poursuite de livraisons à échéances courtes et fixées donne une vie au produit, onserve l’interêt du client et permet la création de « buzz » autour du produit.

Bonne livraison et bon projet à tous.

Durée des sprints : deux, trois ou quatre semaines ?


Je vois souvent des équipes qui se demandent quelle devrait être la durée de leurs sprints ? Deux, trois ou quatre semaines ?
En fait pour répondre à cette question, il faut d’abord comprendre quelles sont les differentes variables qui influencent ce choix.

Première variable : la taille de l’équipe.
On le sait, les équipes scrum doivent être constituées de 3 à 9 membres. On parle tout de même d’un ratio du simple au triple.
Des équipes de 3 personnes ont évidemment une capacité de développement moindre, partant de cette idée, des sprints courts ne permettront pas suffisament d’ajout de valeur, les sponsors (stakeholders) risquent de perdre interet pour les sprint review.
À l’opposé, de grosses équipes utilisant des sprints longs, vont produire beaucoup de valeur à chaque sprint et necessiter beaucoup de travail de plannification en amont des sprints. Il permettrons aussi moins de changements à faible coût.

Deuxième variable : l’experience de l’équipe
Si il s’agit d’une équipe qui a peu d’experience tant au niveau de l’approche agile qu’au niveau du travail collectif, des sprints plus courts entraineront une plus grande fréquence des sprint retrospective. Plus une équipe est jeune, plus les retrospectives, si elles sont bien conduites et si on applique les pistes d’améliorations que l’on y découvre, sont importantes. Elles sont l’élément principal de l’amélioration continue de l’équipe.
Pour une équipe plus aguerrie, le besoin d’amélioration est moins présent on peut donc se permettre d’étirer un peu les sprints.

Troisième variable : la disponibilité du Product Owner
Plus les sprints sont courts, plus les meetings de sprint planning, sprint review et sprint retrospective sont fréquents, bien qu’ils soient de durées proportionnelles au sprint, plus ils sont fréquents plus c’est demandant pour le po.
Un Product owner qui gererait plusieurs projets ou équipes aurait beaucoup de difficulté à tenir le rythme.
À l’opposé un po qui ne gère qu’une seule équipe pourrait trouver des sprints de 4 semaines beaucoup trop longs et manquant d’interaction.

Quatrième variable : le besoin de changement, de réactivité
Lorsque le projet nécessite une plus grande réactivité dûe à une compétition plus féroce, un domaine jeune en plein évolution, des sprints courts offriront au Product Owner la souplesse nécessaire pour assurer une grande compétitivité.

Sachant qu’il est peu recommandé de changer la durée des sprints en cours de release, avant de définir celle-ci, verifiez ces variables pour vous assurer le bon choix.

Réussir ses Sprint Rétrospective : La magie des post-its


J’agis à la fois en tant que Product Owner et facilitateur Agile au sein de ma compagnie ; nous avons pris ce virage depuis peu et je remarque une certaine difficulté lors de la rétrospective.

Dans tout le processus Scrum,  la rétrospective est le meeting le moins mécanique et par conséquent aussi le meeting ou les membres de l’équipe ont le plus de difficulté à s’exprimer.

J’ai donc cherché les raisons de cette difficulté et j’en arrive à ces conclusions.
il s,agit surement d’une certaine forme de gêne dans des équipes qui ne sont pas habituées à :

  • S’interroger sur leurs interactions
  • S’interroger sur leur façon de collaborer
  • Se confronter respectueusement.

J’ai donc essayé différentes pistes.
Dans un premier temps je leur exposais simplement les 2 premieres questions : Qu’est-ce qui à bien fonctionner dans ce sprint ? Qu’est ce qui aurait pu mieux fonctionner ?
Résultat, quand un parle les autres n’osent pas exprimer d’avis contraire. Ils ont beaucoup plus de misère à exprimer ce qui aurait pu être  mieux. On arrive rapidement au silence, les rétrospectives sont donc peu productives.

J’avais pensé que lors du sprint suivant ,j,aborderai les questions une par une et ne permettrai à chaque personne de n’exprimer qu’une opinion à la fois. Finalement j’ai opté pour une autre approche que je vous présente ici.

On commence donc avec la première question que l’on écrit au tableau : Qu’est-ce qui, lors de ce sprint, a selon vous été une réussite ?
On ecrit ensuite les thėmes pour lesquels on veut répondre à la question, dans notre cas ce sont les suivants :

  • la technologie & les outils
  • l’équipe (Scrum dev + Scum master + Product owner)
  • l’équipe étendue (équipe + experts externes)
  • le processus Scrum
  • les actions du Scrum master
  • les actions du Product Owner

On part un timebox de 15 minutes, chaque membre de l’équipe doit ecrire une opinion/fait par post-it en spécifiant le thème.
En quelques minutes les opinions évidentes sont notées, le reste du timebox force les participants à identifier les éléments moins marquants.

On ramasse les post-it et on les place sous les thèmes correspondants.
On commence par remarquer les thèmes qui récoltent le plus et le moins de post-it, donc les zones de pus grands succès sur lesquels on va pouvoir se reposer pour perpetuer le succès.

Par thème, On les lit à haute voix et ensemble on les regroupe par idée.
Cet exercice permet à chacun de se situer par rapport à l’équipe, voir si ils partagent une vision commune.


image





















On répète le même exercice pour la question deux : Qu’est-ce qui, lors de ce sprint, aurait selon vous pu être mieux réussi ?
Ensuite en équipe on trouve des pistes d’amélioration des points de la question 2.

Voilà, bonne rétrospective !