Posté par jc-Qualitystreet le 5 février 2010
Les coachs Agiles apprécient les acronymes … c’est vrai qu’ils permettent de faire passer simplement quelques messages clés auprès des équipes.
Alors vous m’entendrez souvent au cours de mes missions de coaching insister sur :
Le backlog de produit, c’est en résumé la liste des exigences du produit ou plus exactement la liste de tous les éléments sources de valeur qui vont nécessiter du travail de l’équipe pour réaliser le produit. On y trouve donc essentiellement des User Stories mais aussi des élément plus techniques voire des défauts détéctés .
Le backlog de produit est un des 3 artefacts SCRUM, sous la responsabilité du Product Owner, c’est l’élément central de tout notre dispositif agile. Il se construit (se priorise et s’estime collectivement) en général dans le Sprint 0.
Alors, qu’est ce qui caractérise notre backlog de produit ? Il est DEEP tout simplement :
- D = Détaillé de manière appropriée (le backlog contient des éléments au bon niveau de granularité : suffisamment petits, détaillés et compréhensibles pour ceux devant être réalisés dans les sprints qui arrivent)
- E = Estimé (chaque élément du backlog est estimé de manière relative, les uns par rapport aux autres; une estimation menée collectivement par l’équipe: c’est le Planning Poker)
- E = Evolutif (le backlog n’est pas figé; il émerge dans le sprint 0 mais change au fur et à mesure de l’avancement du projet: ajout, retrait, changement de priorités)
- P= Priorisé (les éléments du backlog sont priorisés: du plus important au moins important; rappelez-vous l’objectif est de livrer le plus de valeur (top priorité) le plus tôt possible)
Simple, non ?
Posté par jc-Qualitystreet le 13 novembre 2009
Noel approche et les enfants le savent, du coup voilà à quoi j’ai eu droit le weekend dernier…
Mes enfants : « Papa … papa … pour Noel on fait le jeu des post it »
Moi : « D’accord les enfants mais cette fois on va faire un petit peu différemment … »
Car depuis ce billet « Des priorités pour le Père Noel », j’ai bien évidemment eu le temps d’améliorer le process 
, même si côté contraintes, c’est toujours plus ou moins la même chose :
- Le temps du Père Noel est compté
- Son traineau n’est pas extensible
- Les délais sont serrés
- La date de livraison ne peut pas bouger
- Le Père Noel a un grand nombre d’enfants à satisfaire
En outre, mes enfants, en bons Product Owner qu’ils sont, ont compris qu’ils ne pouvaient pas tout avoir (même s’ils en veulent toujours plus), et que le fait d’avoir été sage (ou non) pouvait « potentiellement » avoir un impact sur ce qu’ils allaient recevoir… d’où la nécessité pour eux de fixer des priorités !
SCRUM / XP depuis… la maison !
Ou comment nous fixons des priorités pour la lettre au Père Noel
Temps 1 (Optimisé) : Brainstorming et collecte des données
Lecture passionnée depuis quelques semaines, et recherche intensive dans plusieurs sources, interview du petit frère et découpage des cadeaux potentiels.
Temps 2 : Initialisation du (ou des) Backlog(s)
Les images sont découpées : une enveloppe pour chaque enfant. Je colle chaque image cadeau sur 1 post it. 1 cadeau par Post it.
Le backlog est alors initié.
Temps 3 : Priorisation du (ou des) Backlog(s)
Les post it sont posés sur le sol. J’ai demandé à mes enfants de les classer par ordre de préférence « à la file indienne » : en haut, ceux dont ils ont le plus envie, les plus importants pour eux …
…..
….
Temps 4 : Affichage du (ou des) Backlog(s)
Les post it sont priorisés sur le sol. Il nous restait à trouver un petit coin de mur ou de porte pour les mettre à la verticale (management visuel…). Un peu de patafix et le tour est joué.
Pour la grande (pas trés raisonnable):
Pour le petit frère (beaucoup plus raisonnable …):
BILAN: On a passé un bon moment et les enfants sont contents
Ma femme et moi nous chargeons de l’estimation en points-euros :)
Posté par jc-Qualitystreet le 11 août 2009
Le Story Map est l’un des éléments forts que j’ai retenus de ma dernière certification Product Owner, délivrée par Arlen Bankston (LithtSpeed).
Jeff Patton - Story Map - http://agileproductdesign.com
Intégré à un large radiateur d’informations, le User Story map est une dose supplémentaire d’UX (user Experience) dans votre projet Scrum, le complément idéal, voire indispensable de votre Backlog de produit.
Contrairement au Backlog de produit, le Story Map est multidimensionnel, plus visuel et plus collaboratif notamment au moment de sa construction.
Les règles sont simples:
- Le User Story map représente donc le backlog de produit
- Il est lié aux Personas, placés sur la gauche du Story Map
- Il se lit sur 2 axes:
- Horizontal, l’axe temporel - séquences d’action, que les ergonomes et les analystes apprécieront puisqu’il se fonde sur les analyses de l’activité et analyses métier
- Vertical, l’axe priorité, qui servira à définir quelles User Stories seront retenues sur la release ou sur le sprint
- Les grandes activités sont placée au dessus sur une ligne horizontale (les post it jaunes sur la photo qui suit), puis sont décomposées en User Stories (les post it bleus).
- Les User Stories sont affichées en colonne sous l’activité dont elles dépendent et classées par priorité. La User Story la plus nécessaire à la réalisation de son Activité est placée le plus haut, les autres suivront par ordre d’importance (on peut se réfèrer au modèle de Kano pour le déterminer). Une décomposition trés fine et le respect des critères INVEST pour les User Stories est plus que souhaitable
Jeff Patton - Story Map - http://agileproductdesign.com
Avec le Story Map, vous avez :
- Des user Stories enfin liées les unes aux autres (c’était une vraie lacune de la technique des User Stories jusqu’alors)
- L’association de toute une séquence d’actions et d’un Persona
- Un point d’entrée évident vers d’autres livrables Ux, type Storyboards…
- Une représentation concrète des flux et des séquences dans une approche très orientée Utilisateurs
- Une véritable aide à la priorisation qui met l’accent sur les fonctionnalités nécessaires à la réalisation d’une activité
Bref, un Backlog de produit plus performant, un découpage des sprint et des release plus aisé, et une meilleure appropriation des backlogs (souvent indigestes) par les équipes.
Le User Story Map fait enfin VIVRE le Backlog aux yeux de tous!
