Initiation – Product Planning

Nous Contacter

Vue d’ensemble

Vision Produit

Pour quoi faire?

  • Assurer un minimum de consensus sur le cadre Produit?
    • Définir la raison d’être du produit (vision du sponsor et contexte métier)
    • Identifier les parties prenantes et récolter leurs besoins
    • Aligner les parties prenantes sur les objectifs et résultats à atteindre
    • Faire émerger le Backlog Produit initial  (et le Roadmap)
  • Assurer un minimum de consensus sur le cadre Processus
    • Ajustement SMQ de l’organisation au produit
    • Mettre en place les formations nécessaire
    • Définir les cycles de Sprint
  • Assurer un minimum de consensus sur le cadre Equipe
    • Organisation structurelle / Rôles & Responsabilités / Interactions
    • Réserver Salle et matériels pour l’équipe (attention équipe virtuelle!)
    • Mettre en place les environnements techniques
  • Identifier et évaluer les risques liés au programme
    • Poser les questions qui font mal et identifier les risques des le début sans tomber dans l’excès de détails
    • Complétés et mise à jour tout au long du cycle

Qu’est ce que c’est?

Comment passer du problème à la solution?

Récit

 Qu’est-ce qu’un récit utilisateur?

  • Un Récit Utilisateur est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur.
  • Il est caractérisé principalement par un « Titre », une « Estimation initiale », une « Priorité » et des « Critères d’acceptation »
  • Le modèle de structure d’un Récit Utilisateur
    • En tant que <rôle, persona, type utilisateur> Qui?
    • Je veux <fonctionnalité, tâche, action> Quoi?
    • Afin de <valeur ajoutée, résultat> Pourquoi?
  • Exemple
    • Titre: « Saisir Info Employeur »
    • Estimation: 20 Points
    • Priorité: 1 (Selon modèle WSJF)
    • Description:
      •    En tant qu’utilisateur, je veux pouvoir saisir les information      d’un employeur afin de les réutiliser lors de la transmission   de l’impôt source du mois

Qu’est-ce qu’une description 3C?

Qu’est-ce qu’un récit INVEST?

Critères d’acceptation

Tâche d’implémentation

Qu’est ce qu’un cas d’utilisation métier?

Qu’est-ce qu’un cas d’utilisation?
C’est la spécification d’une séquence d’actions, avec variantes éventuelles, réalisées par le système en interaction avec les acteurs du système. Il décrit le comportement attendu des utilisateurs et du système

Qu’est-ce qu’un cas d’utilisation Métier?
C’est un cas d’utilisation simplifié, abstrait et général qui capture les intentions de l’utilisateur de façon indépendante de la technologie et de la solution.

Comment l’utiliser pour décrire un Récit?

  • Les buts de l’utilisateur sont décrits dans les récits utilisateur
  • Les chemins pour atteindre ces buts peuvent être décrits par les interactions entre l’utilisateur et le système via un cas d’utilisation métier

Exemple

  • Récit: En tant que Visiteur, je veux communiquer mes coordonnées à l’établissement afin d’être contacté ultérieurement sur les formations sélectionnées
  • Cas d’utilisation: Communiquer des renseignements

Cas d’utilisation et scénario

Qu’est-ce qu’un Scénario?
Un chemin particulier au travers de la description abstraite et générale fournie par le cas d’utilisation

Comment ça marche?
On utilise les Scénarios pour décrire l’ensemble des flux de valeur d’un cas d’utilisation

  • Scenario nominal: décrit le flux normal, le scénario typique de succès.
  • Scénarios alternatifs: décrit les autres flux possibles, avec branchements et incidents, de parcours, conduisant aussi bien au succès qu’à l’échec

Avantages

  • Vivant et descriptif
  • Explore l’ensemble des flux de valeur
  • Focus sur le besoin utilisateur

Inconvénients

  • Difficulté de se maintenir au niveau du POURQUOI et de ne pas tomber dans la SOLUTION
  • Souvent trop large pour un Sprint
  • Pas assez détaillé pour un Sprint

Qu’est ce qu’un récit technique?

Un récit technique est un besoin, une contrainte, ou une exigence non-fonctionnelle, qui n’a pas de Valeur Directe pour le PO

  • Types de Récits Techniques
    • Infrastructure Produit – support direct aux récits fonctionnels
    • Infrastructure Equipe – support pour l’équipe et leur capacité à livrer le produit (test, planning, etc.)
    • Refactoring – identifie les besoins de remaniements (code, conception, outillage, etc.)
    • Bug Fixing – Correction d’anomalies
    • Prototypes –  Recherche de solutions et étude de faisabilité (spike, apprentissage, expérimentation, architecture, conception, etc.)
  • Exemples
    • Installer un serveur de build en continu
    • Mettre à jour Jira
    • Remanier la couche d’accès au données

Comment gérer les récits techniques

La stratégie ci-dessous permet de limiter les récits techniques et le cas échéant d’éviter les dettes techniques en dégageant du temps dans les sprints pour les traiter

  • Eviter les récits techniques – rechercher un moyen de transformer le récit technique en récit normal avec une valeur métier mesurable
  • Si la transformation ci-dessus n’est pas possible, voir si le travail peut être fait en tant que tâche dans un autre récit
  • Si les deux méthodes ci-dessus échouent, alors définir un récit technique
  • Maintenir une liste séparée des récits techniques (dans le backlog)
  •  Utiliser le «Facteur Focalisation» pour négocier avec le PO et obtenir un peu de temps dans le Sprint pour traiter les récits techniques

Stratégie de décomposition INVEST

10 stratégies de décomposition d’un récit en récits INVEST

  • Workflow Steps
    L’utilisateur accomplit une tâche selon un workflow bien établi. On découpe les stories par étapes qui seront développées de façon incrémental
  • User Scenarios (Base and alternative scenarios)
    On obtient un Récit pour le scénario principal, le cas où tout se passe bien, on en a d’autres pour les cas d’erreurs ou les scénarios alternatifs (quand il se passe évènement x; quand il se passe évènement y)
  • User Scenario Subflows
    Le cas est plus précis, on découpe cette fois-ci une séquence au sein d’un scénario…
  • CRUD (Create, Retrieve, Update, Delete)
    Souvent le mode de décomposition le plus évident; il est souvent utile de découper ou d’en faire deux en même temps…créer un compte, le consulter, le modifier et le supprimer
  • Data Type or Format
    On joue sur le type d’objet (ex : compte titres, espèces… messages en français, anglais, espagnol…)
  • Entry, Output and Configuration Types
    Des variations d’un point de vue matériel ou non, selon les configurations mais aussi en termes de moyens de saisie. Cela peut se jouer aussi  au niveau de l’interface…
  • Persona or Actor
    On décompose les récits en fonction du rôle et de celui qui va utiliser le produit
  • Maturity Level (well known part, spike, …)
    Le niveau de connaissance acquis sur une fonctionnalité est un bon critère de décomposition…Un récit pour ce qui est connu, un autre là où c’est moins maîtrisé. Cela peut déboucher sur un spike (un récit un peu particulière orientée exploration)
  • Complexity Level (simple mode followed by more complex modes)
    Un récit va par exemple décrire une fonctionnalité dans son mode de réalisation le plus simple, d’autres suivront par un niveau de complexité plus grand
  • Quality Level (Performance, Usability, Security, …)
    Performance, Sécurité, Utilisabilité… ces exigences non fonctionnelles constituent le plus souvent des conditions de satisfaction pour des user stories spécifiques mais elles peuvent permettent également de distinguer des user stories entre elles (ex : afficher en moins de 60 sec, moins de 30 sec ; données en temps réels ou non…)

Product Backlog

Qu’est ce que c’est?

  • Le Backlog Produit est l’outil central de planification incrémentale d’un produit (programme)
  • C’est une liste priorisée par valeur métier (WSJF) d’articles ou récits (besoins et exigences que veut le client, exprimé dans son vocabulaire et sa terminologie métier)

Pour quoi faire?

  • Le Product Backlog, sous la responsabilité du CPO et du CoOp, centralise la gestion et la planification incrémentale du produit. Elle permet entre autre de répondre à certaines questions fondamentales telles que:
    • Comment identifier la liste de tout ce qui doit être fait dans un programme?
    • Comment analyser, concevoir et inspecter le produit de façon collaborative?
    • Comment prioriser les attentes et les besoins du client et planifier les sprints de façon collaborative?
    • Comment les récits s’agencent ensemble pour réaliser les processus métier?
    • A quels processus métier appartient un récit?
    • Comment les processus métiers sont réalisés à partir des récits?
    • Quels sont les processus métiers en cours d’implémentation dans une Release / Sprint?
  • Le Product Backlog se présente sous plusieurs vues opérationnelles :
    • Vue Liste ordonnée  (liste priorisée de tout ce qui doit être fait dans un programme)
    • Vue hiérarchique Epic-Features-Stories ou Activité-Tâches-Récits (montre l’agencement des récits mais de façon statique)
    • Vue Story Map (permet de répondre à toutes les questions fondamentales)
    • Vue Kanban (visualisation du flux d’activités de gestion des récits)

Story Map

Qu’est ce que c’est?

Le User Story Map est une vue systémique du Backlog Produit permettant de visualiser la décomposition des Récits plus grands en Récits plus petits (INVEST)

  • Identification des Activités au niveau des Processus Métier
  • Décomposition des Activités en Récits de haut niveau (Tâches Utilisateur)
  • Décomposition des Tâches Utilisateur en Récits INVEST en appliquant la stratégie décrite au chapitre  stratégie
  • Les Récits sont ensuite groupés par Release de Production
  • Visualiser les scénarii utilisateur en traversant les récits
  • Favorise l’analyse et la conception collaborative du produit

Illustration

Utilisation effective

  • Le Story Map est testé en le parcourant visuellement et en discutant avec le PO ou les Parties Prenantes
  • En le parcourant on peut
    • Rajouter des détails
    • Réarranger les priorités
    • Réviser et réécrire les récits
  • Les techniques de visualisation aident à imaginer le produit plus concrètement
    • Ecriture des Scenarii Utilisateur
    • Création des Maquettes Ecran et Story-board

Exemple de parcours

Paramètre de raffinement

Exemple raffinement

Workshop de création

Product Planning Kanban

« Nos experts travaillent avec vos équipes sur vos projets pour vous accompagner et aider à sécuriser vos engagements quel que soit votre niveau de maturité Agile. Nous vous aidons à mettre en place écosystème et conditions d’amélioration continue de votre Organisation.  Voir nos services »

Nous Contacter