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 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 4 février 2012
Activité#4 du praticien AgileUX…
Le praticien AgileUX va initier puis construire l’architecture de l’information de manière collaborative
L’architecture de l’information c’est l’organisation du contenu et des fonctionnalités d’un point de vue cognitif et graphique pour répondre aux besoins et attentes des utilisateurs finaux.
Architecture de l'information : un élément d'UX
L’architecture de l’information est une activité incontournable de toute projet IT ; outre le fait de donner du sens, dans un contexte de développement Agile, cette activité va proposer la fameuse Big Picture, tant attendue par mal d’intervenants, et va rassurer à la fois les Equipes IT et le Business. Elle facilitera ensuite le travail de tests.
Arborescence
La Big Picture : High level et structurante
Entrer dans une dynamique agile signifie l’ABANDON de spécifications détaillées, travaillées pendant des mois et figées au démarrage du projet, AU PROFIT d‘un travail de spécification plus léger au départ, mais aussi progressif et surtout continu (notamment au travers des workshops User stories et du travail portant sur le Backlog de produit).
Concept Model par Daniel M. Brown
Néanmoins, et je dirais encore plus sur un projet SCRUM, même si ce travail de spécification ergonomique peut sembler plus léger au départ, les premiers éléments d’architecture d’informations sont à maîtriser dés les premiers sprints du projet (sur la base d’informations potentiellement recueillies au préalable, tri de cartes, Kano…).
Modèle de Kano
Il s’agit pour le praticien AgileUX d’aller à l’essentiel, de réflechir en terme de valeur pour sa prore activité et de se mettre au service à la fois du Product Owner et de l’Equipe.
La TO DO List du praticien AgileUX pour l’architecture de l’information
- Clarifier et catégoriser les informations
- Soutenir le PO dans son effort de priorisation des fonctionnalités et des contenus
- Initier puis approfondir de manière collaborative une première structure d’informations efficace
- Déterminer les système d’information le plus approprié
- Tester puis affiner ces éléments structurants
Système de navigation - Pages intèrieures
Posté par jc-Qualitystreet le 17 octobre 2011
Ou 1pt=3 jours… etc
Nouveau point d’attention pour le coach agile dans son accompagnement des équipes qui cherchent à faire du SCRUM car même si une telle correspondance est tentante pour certains, elle vous sort de la dynamique d’estimation agile et vous éloigne petit à petit de l’esprit Agile…
1 point => 2 DAYS!!!
Même avec des équipes ayant mis en place des pratiques agiles depuis quelques mois, voilà ce qu’on peut parfois observer…
« 4 points, on va la mettre à 4 points… 4 points c’est 8 jours normalement, non ? »
Alerte ! Car derrière l’agilité se cachent à la fois une nouvelle façon d’estimer et plus largement une autre façon, réaliste, de considérer les estimations :
« Nous autres Etres humains ne sommes pas câblés pour estimer on se plante tout le temps… »
La vision concrète, réaliste et adaptative (vs prédictive) de l’agilité nous amène à ré envisager 4 éléments clés relatifs aux estimations ; avoir l’esprit agile c’est donc avant tout revoir :
- L’importance et la place accordées aux estimations
- L’effort nécessaire pour les produire (Just enough)
- La façon de les réaliser: l’estimation agile est COLLECTIVE, faite JUSTE à TEMPS, par CEUX QUI VONT FAIRE LE BOULOT, RELATIVE (stories estimées en terme d’effort les unes par rapport aux autres), RÉVISÉE régulièrement
- La durée de vie des estimations
Mon challenge :
- Sensibiliser Directions, Management et Programmes sur la question des estimations (agiles)
- Former et accompagner les équipes sur la façon de réaliser ces estimations (Release planning, Planning poker….)
- Eviter toute dérive et tentative de correspondance Point/ Heures (certes compliqué qd l’équipe travaille comme ça depuis quelques temps)
- Toujours challenger le «Just enough, Just in Time»
- Insister sur la notion d’Equipe et la nécessité de bien se connaitre
« + l’Equipe avancera ensemble, + l’Equipe se connaîtra, + ses estimations (just enough, just in time) seront fiables »
Mes autres Alertes:
Commentaires:
Classé sous: Agile
