Posté par jc-Qualitystreet le 5 mars 2013
L’atelier « User Story Mapping » (inventé par Jeff Patton) devient désormais un grand classique de mes activités de coaching agile auprès des Product Owner. Une activité que j’apprécie tout particulièrement puisque c’est mettre, à moindre coût, quelques éléments de réflexion UX dans une belle dynamique Agile… un grand pas vers l’AgileUX!
Résultat d'un Atelier StoryMap avec un Product Owner motivé
L’activité est à la fois ludique et très efficace ; elle permet très rapidement de donner vie au produit dans une représentation différente, (multidimensionnelle et plus riche) de celle offerte par le Backlog de produit… Lire la suite
Posté par jc-Qualitystreet le 24 février 2013
“Product Owner” est un rôle qui a débarqué dans les organisations françaises avec Scrum, l’une des méthodes Agiles. Aujourd’hui, alors même que ces organisations semblent prendre conscience de la nécessité d’être Agile, au-delà de la méthode utilisée (Scrum , Kanban ou autres), le rôle de Product Owner reste et s’installe pour de bon !
Product Owner : le Responsable Produit…
Et le représentant du Métier, des Clients et des Utilisateurs. Wahou !
Lire la suite
Posté par jc-Qualitystreet le 18 novembre 2012
Noël approche et pour la 5ème fois, toujours à leur initiative, nous avons passé un peu de temps ensemble pour faire nos Lettres au Père Noël… au programme, du jeu, du plaisir et de la bonne humeur, dans un esprit Agile 
Pour ceux qui n’ont pas suivi:
Mêmes contraintes que les années précédentes
- Le temps du Père Noel est compté…
- Son traineau n’est pas extensible…
- Les délais sont serrés…
- Le Père Noel a un grand nombre d’enfants à satisfaire…
- La date de livraison ne peut pas bouger… :)
- Livraison uniquement sur le site Parisien cette fois-ci
Le Workshop
Pas besoin d’ouverture, tous les protagonistes, dont les principaux âgés de 5 et 7 ans ont une vision claire du projet et de l’objectif du workshop. Ils sont prêts (depuis plus d’un mois…) à en découdre! La nécessité de FIXER DES PRIORITES est intégrée… Nous bénéficions en outre depuis quelques mois d’un petit indicateur visuel pouvant aider le Pere Noel dans son arbitrage: la liste des colères et les Etoiles du courage…
Les Etoiles du Courage
Etape1: Besoins, Brainstorming
Brainstorming - Catalogues
Etape 1bis: Prototypage (NEW!!!)
Une nouvelle activité initiée par Eva…
un peu de sketching pour envisager un nouveau format de Lettre …. Bonne idée ma Fille!
Etape 2: Création du Backlog
Les images sont découpeés, et les backlogs initiés
toujours 1 cadeau “potentiel” par postit…
1 cadeau - 1 post It
Etape 3: Priorisation du Backlog
Les postit -cadeaux sont placés sur la table . Mes enfants, en bon PO, font alors leur effort de priorisation, pas toujours facile pour certaines…
Il va falloir .... choisir! Mademoiselle
et ordonnent finalement un nombre restreint de post it …
Dans les années passées, c’était à la fil indienne: en haut, les jouets dont ils ont le plus envie, ceux qui sont le plus source de VALEUR à leurs yeux…. cette année de gauche à droite…
Puis passage de la table au poster, avec une nouvelle représentation visuelle pour la liste des items retenus. La thématique de l’année 2012: la Fleur et ses pétales avec en son coeur le cadeau dont ils ont le plus envie…
Etape 4: Customisation du Backlog
Depuis l’année dernière, cette étape de customisation….
est devenue tout simplement cruciale!
Etape 5 : Affichage du Backlog et Version imprimée: la lettre au Pere Noel
Lettre au Pere Noel Version Solal
Il ne reste plus qu’à afficher le poster dans la chambre des enfants pur lui assurer un maximum d’accessibilité et de visibilité.
Ensuite on imprime au format A4 la photo de ce beau backlog, la glisse dans une enveloppe et on l’expédie au pôle Nord… Voilà le tour est joué
C’était Super!
Commentaires:
Classé sous: Agile
Posté par jc-Qualitystreet le 27 février 2012
Un titre qui peut vous sembler exagéré… et pourtant ce RDV en cours de sprint est tout simplement crucial pour l’Equipe qui se veut Agile !
Mon message est clair :
Sans Backlog Refinement, vous n’atteindrez pas cette agilité bien huilée que vous recherchez et ces résultats que vous attendez
et simple :
Ceux qui le négligent, ceux qui l’oublient le paient inévitablement ; ceux qui l’adoptent et le réalisent dans de bonnes conditions en redemandent…
Une équipe performante à l'oeuvre
Le Backog Refinement est un workshop qui se déroule une à deux fois par sprint, souvent à mi-sprint. Comme son nom l’indique, ce workshop est centré sur le Backlog de produit (c’est à dire la « liste de tous les éléments sources de valeur et nécessaires à l’équipe pour réaliser un produit »). Alors affinage, nettoyage, entretien, maintenance, ou en anglais « grooming », les mots varient mais j’avoue avoir une très nette préférence pour le terme Refinement, popularisé par Craig Larman.
Définitivement collaboratif, le Backlog Refinement doit impliquer tout le monde, du Product Owner (soutenu ou pas par un expert UX ou un Business Analyst), au ScrumMaster en passant par TOUS LES MEMBRES DE l’EQUIPE. Durant mes formations et mon coaching, je présente le Backlog refinement comme un must, le 5 eme RDV incontournable, qui vient s’ajouter aux 4 cérémoniaux Scrum décrits par Sutherland et Schwaber, inventeurs de la méthode Agile la plus populaire… des auteurs qui persistent à limiter la visibilité de cette activité essentielle de préparation tout en reconnaissant paradoxalement son existence!
“Product backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team.” Scrum Guide July 2011 p13
Et je persiste à penser que “légitimer” son existence en tant que cérémonial Scrum ferait gagner du temps et de l’énergie à pas mal d’Equipes, car même si le format et la durée peuvent varier (3 à 4 heures à mi sprint en une fois ou plus courts en deux temps une fois par semaine), les objectifs, l’agenda, éléments d’entrée / sortie sont clairs, pour une valeur évidente.
Agenda- Facilitation Backlog Refinement
Vous l’aurez compris, le Backlog Refinement est un RDV avant tout collectif qui dans les contextes webs et digitaux devient un moment d’expression et de facilitation privilégié pour les experts UX où il s’agira en priorité de décortiquer, d’explorer, de modéliser collectivement le contenu potentiel du sprint qui va démarrer quelques jours plus tard.
Ni trop tôt, ni trop tard dans le Sprint…
Tenir ce Refinement à mi-sprint permet au spécialiste UX, au product Owner ou même à l’équipe de de disposer de suffisamment de temps pour pouvoir le cas échéant peaufiner son besoin, faire un travail de spécifications supplémentaire, explorer une problématique technique ou confirmer des hypothèses auprès des utilisateurs finaux.
Le début-milieu de la seconde semaine sur un sprint de 3 semaine ou la fin de la première semaine pour un sprint de 2 semaines sont des moments propices pour organiser le Backlog Refinement. Le faire le dernier jour du sprint ne présente donc que peu d’intérêt.
Ce workshop peut à son tour donner lieu à des mini workshops spécifications côté Product Owner et/ou Equipe.
Focus sur le sprint n+1… mais pas seulement
J’attends que les équipes se focalisent sur le sprint qui arrive et qu’elles soient en mesure de répondre à cette question :
« Serons-nous Prêts à développer les user stories se trouvant en haut de la pile, ces user stories que nous sommes susceptibles d’embarquer au Sprint suivant ? ».
Ce questionnement implique une activité de modélisation ainsi qu’un travail portant à la fois sur les conditions de satisfaction et sur des exemples (lien avec l’approche ATDD) illustrant les fonctionnalités à développer. Il implique aussi le découpage de certaines users stories trop grosses être développées dans un sprint.
Néanmoins, le focus sur la préparation du sprint suivant n’est pas le seul objectif du Refinement. C’est aussi le moment idéal pour discuter des changements sur le backlog (rappelez-vous mon backlog est DEEP, évolutif, des items peuvent disparaitre, d’autres peuvent émerger, les priorités changent inévitablement.)
Il aussi souhaitable d’anticiper les risques ou impacts de certains éléments prévus à moyen terme dans les sprints n+2, n+3… besoins de spécialistes, impact techniques, ergonomiques, en terme d’activités de déploiement, de tests ou de support…
Le Backlog refinement: que des bénéfices si on joue le jeu!
Ce workshop collaboratif:
- Donne du contexte et des élements de conversation aux User Stories, pourquoi pas en se basant sur la checklist User Story pour s’assurer qu’on n’oublie rien
- Assure une certaine fluidité et de la sérénité dans le déroulement des sprints
- Illustre et précise les exemples et conditions de satisfaction, qui seront confirmées au moment du Sprint Planning
- Offre un pur moment d’intense collaboration: interactif, visuel, concret et source de feedback…
Bref, le Backlog Refinement, adoptez le sans modération !
Posté par jc-Qualitystreet le 9 février 2012
L’art de la spécification dans un contexte Agile et notamment SCRUM est avant tout une affaire de collaboration, une affaire de comportement. Les User Stories sont un format (que j’apprécie beaucoup) qui permet d’engager la conversation mais qui ne se suffit pas à lui-même… (voir le PROTOTYPAGE AGILE)
Bref, l’idée derrière cette checklist (reprise de Lisa Crispin et Janet Gregory) est de faciliter le boulot du Product Owner en lui rappelant les éléments nécessaires que ses User Stories arrivent Prêtes (ce fameux Ready) en début de sprint.
User Story CheckList
Cette checklist doit être envisagée comme un guide de conversation et non comme un énième format de spécification ! Elle permet aussi d’identifier les éléments complémentaires nécessaires à la réalisation et au test de la story (ex : Wireframe ; Diagramme d’activité…) et fait le lien avec une démarche ATDD.
La partie haute et les premiers éléments sont initiés par le Business; le reste se construit dans un mode « Juste à temps - Juste ce qu’il faut » de manière collaborative avec l’Equipe.
Rappelez- vous Feedback et Collaboration...
Quelques lectures pour approfondir le sujet User Stories:
Posté par jc-Qualitystreet le 23 janvier 2012
Vous savez que je suis un fervent défenseur de l’utilisation d’un backlog de produit (liste de tous les éléments sources de valeur et nécessaires à l’équipe pour réaliser un produit) “PHYSIQUE” c’est à dire affiché au mur au sein du radiateur d’informations… du coup aujourd’hui, je vous propose un nouveau format “enrichi” pour ce backlog…
Backlog de produit Physique "enrichi"
Ce format de backlog présente tous les avantages d’un backlog physique: visibilité, transparence, finalité, et permet de répondre à un besoin exprimé sur le terrain par certaines équipes que j’ai pu accompagner. En effet même si un gros travail d’estimation de l’EFFORT (exprimé en point) de chaque item du backlog est fait au démarrage du projet, l’équipe est donc régulièrement amenée à réaliser des estimations “à la volée” puisque à chaque sprint des items sont affinés, de nouveaux éléments peuvent surgir ou certaines estimations peuvent être revues du fait de nouvelles informations.
Les estimations agiles ont cette spécificité d’être à la fois collectives (les items sont estimés par l’Equipe dans des sessions de planning poker) et relatives (les items sont estimés les uns par rapport aux autres); elles nécessitent des points de répères; d’où l’idée de visualiser en permanence ces repères utilisés initialement en workshop d’estimation… et de proposer un backlog “enrichi”
Faciliter l'estimation agile en workshop
Attention: il vous faudra un peu de place !!
Commentaires:
Classé sous: Agile
