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.