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 …

Advertisements

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.