Ecrire de bonnes US en 5 minutes

Lors du Scrum Wine 15#2 de ce soir voici le support de ma présentation : "Ecrire de bonnes US-  en 5 minutes" 

Ecrire de bonnes user stories - en 5 minutes - scrum wine v1.0 from Olivier Patou

Management visuel et amélioration continue

L'organisation des POs

En début d'année je vous publiais un post sur notre mise en oeuvre de Kanban au sein de notre équipe de "PO". Notre objectif était de mieux suivre notre flux de production des US afin d'être en mesure d'alimenter convenablement nos équipes Scrum, de visualiser les goulets d'étranglement et d'améliorer la communication au sein de l'équipe.

Aux mêlées des POs participent : 

• Les POs - 8 personnes,
• Les Chefs de Projet - 5 personnes : exerçant parfois le rôle de PO,
• Les Coordinateurs Fonctionnel - 2 personnes : identifient les impacts entre projet et coordonnent les évolutions fonctionnelles par version (vision macro),
• Les experts métier/testeurs - 2 personnes : aident les POs à la conception fonctionnelle et renforcent leur capacité de test de fin de Sprint. Leur feedback sur la logique métier et le fonctionnel est très précieux,
• Un représentant de l'équipe de graphistes / intégrateurs Web,
• Deux architectes techniques

Lors de nos mêlées, nous tenons le 1/4 d'heure sans dépassement, il arrive même qu'elle soit finie avant la fin du temps. Personnellement, je trouve que nous sommes trop nombreux et que l'on n'optimise pas la communication, mais en même temps cela fonctionne et globalement nous en tirons tous des éléments importants. En attendant que nous trouvions un meilleur mode de fonctionnement, nous continuerons donc nos mêlées quotidiennes à 20 personnes... 


Après 6 mois d'utilisation, nous avons abandonné notre tableau de suivi de la production des US : le suivi au niveau des US trop fin entre la livraison de la dernière version et le lancement des devs de la nouvelle version,

•  les équipes surchargées n'ont plus pris le temps de mettre à jour le tableau trop d'info tue l'info : le tableau devenais illisible tellement il comprenait d'US (nb US >100)
• pour chaque équipe Lors d'une rétrospective nous avons donc décidé d'abandonner ce format pour un autre, mieux centré sur nos problématiques. 

Nous avons mis en oeuvre un tableau affichant la roadmap des projets permettant visualiser les dépendances qui peuvent exister entre projet. 

L'objectif est donc de pouvoir augmenter notre réactivité lors des changements de planification et ainsi de mieux maîtriser notre gestion du périmètre. La roadmap est enrichie de différentes affiches sur sa gauche : Fiche de vision A3 Toyota du projet, tableau de présence/absence....

Pour l'instant tout le monde a mis en oeuvre ces changements sur son projet et nous allons suivre cette amélioration de près afin d'en mesurer les gains et les difficultés rencontrées. 

Reste à faire en sorte que nos mêlées se focalisent aussi sur ces points.

Une mise en oeuvre de Kanban pour l'IT - itération 2

La première version de notre tableau est terminée. Depuis deux semaines, nous avons commencé la mise en oeuvre :

• Initialisation de la backlog des Features
• Harmonisation des backlogs produit 
• Mêlées quotidiennes façon "Scrum"
• Refactoring du tableau Kanban des activités
• Tableau des problèmes et actions pour le facilitateur
• Initialisation des burnups d'activités par projet, et consolidation des résultats

Ce que nous ne faisons pas encore :

• Tracer les dates d'entrée / sortie dans notre système
• Suivre les indicateurs induits par les mesures de temps de passage
• Limiter le WIP (travail en cours par activité)

Voici nos tableaux :

Tableau des problèmes / actions du facilitateur

Tableau des Features pour l'établissement de la Roadmap produit

tableaux de suivi de la production des US

BurnUp d'activité des tableaux Kanban et BurnUp de produit des équipes Scrum 

Scrum Café 12 : Lego4Scrum

Il y a quelques jours, nous avons joué le fameux atelier de simulation Lego4Scrum décrite sur le site http://www.lego4scrum.com/ et que j'avais joué à un rendez-vous du SUG ( le Scrum Wine Bordelais).


Ce fut une très bonne session, aussi stressante que prévue pour tous les participants.

Auto-organisation

Le Product Owner vient de présenter la liste des choses qui doivent constituer sa ville et 3 équipes de 5 personnes s’auto-organisent afin fabriquer cette ville pour le client.

L’auto-organisation se met en place avec 3 Scrum Masters.

Estimation 

Finalement les fonctionnalités de la ville sont estimées selon une technique d’estimation relative en complexité : Faible, Moyen, Complexe

Valeur métier

Les équipes ont demandé au Product Owner de classer les fonctionnalités par importance en plaçant un « 1 bleu » sur celles que je voulais avoir en premier, puis un 2 sur les autres, et enfin un trois sur celles que je ne voulais pas trop rapidement.

La complexité des fonctionnalités a été reportée à partir de la suite suivante : 

• Faible= 2, 
• Moyen = 5, 
• Complexe =8

Des prototypes ont ensuite été présentés aux équipiers afin de mieux visualiser ce qu’il fallait faire.

Certains ont pensé à demander au Product Owner ce qu’il en pensait : il a tout refusé, mais l’information n’a ni été partagée avec le reste de l’équipe, ni suffisamment comprise par les équipiers.

Les itérations

La première des trois itérations a commencé et les assemblages de briques s’enchainent :
Conception du plan de la ville, premiers bâtiments produits

Rétrospective Sprint 1

« Ou est ma ville ! » crie le Product Owner dans la salle à la recherche de sa ville.
Au bout d’un moment, une timide construction vient se poser sur le terrain nu, quelques fondations décorent le bord de la table.

Un plan de la ville a pu être proposé au Product Owner qui a accepté le plan sous réserve que certaines modifications soient prises en compte

Itération 2

Le terrain est préparé et les premières fonctionnalités voient le jour :

• Le jardin public, 
• Les routes et intersections, 

La fin de l’itération approche : 

Les équipiers préparent le bilan du Sprint : 

• Les fonctionnalités produites sont placées sur le terrain 
• On déplace les post-its initialement prévus dans le Sprint de la colonne « En cours » à la colonne « Fait » 

Rétrospective Sprint 2

Cette fois, le Product Owner n’a pas besoin de demander ou se trouve sa ville :

Les fonctionnalités sont parcourues unes à une et la plus-part sont acceptées par le Product Owner qui réclame tout de même que l’herbe pousse plus vite dans le jardin public….

Sprint 3 : le dernier

La validation des fonctionnalités du Produit est faite au fur et à mesure que les fonctionnalités sont produites (ci –dessus, image en bas à droite avec Benoist et Guillaume qui présentent leur avancement de l’hôpital) : 

• « Plus grand l’hopital » 
• « Plus grand le lieu de culte interconfessionnel » 
• « Plus haut les étages du bâtiment de bureaux »

Les produits sont corrigés et améliorés au fur et à mesure de leur fabrication

Rétrospective finale

Toutes les fonctionnalités sont produites en fin de jeu. La ville et belle et un peu de pelouse a poussé dans le jardin public

Débriefing

Les équipes ont désigné des Scrum Masters pour qu’ils gèrent la relation avec le client, mais ça n’a pas empêché tout le monde de lui poser des questions. Un beau bazar !

La période d’auto-organisation de l’équipe avec l’estimation de la complexité et de la valeur métier a été difficile. Tout le monde posait des questions au PO qui ne savait plus à qui répondre. Stressant !

Les sujets ont été planifiés en 3 Sprints mais sans calculer le ROI. Seule la valeur métier a été utilisée : c’est dommage, l’équipe aurait peut-être pu livrer un peu de valeur au premier Sprint avec l’abri de bus par exemple (très simple à réaliser pour une valeur métier moyenne).

Les informations données par le Product Owner ne sont pas partagées avec le reste des équipes (ex : malgré le refus des maquettes proposées, elles ont été utilisé comme modèle pour le premier Sprint.)

Les équipes ont bien géré leur temps : un chrono a été lancé pour surveiller le temps de production. A la deuxième itération, tout le monde s’est occupé d’organiser la ville sur le terrain avant la fin du temps imparti.

Le jeu a été stressant, comme prévu, pour les joueurs mais aussi pour l’animateur qui devait endosser les rôles distincts d’Animateur, Product Owner et parfois « Super » Scrum Master.


C’était prévu, mais le timing était assez serré. L’organisation des équipes nécessite plus de temps que celui accordé.

Le débriefing final a été un peu écourté également.

Scrum Wine du 25 Septembre 2012

La session a été animée par Fabrice Aimetti et Alexis Monville au Cesi de Blanquefort.

La présentation de Scrum en 5minutes par Alexis était excellente :

• un flot bien maîtrisé,
• aller à l'essentiel 
• laisser le temps pour des questions

J'ai ensuite joué au Légo4Scrum. Nous étions deux équipes de 7 "agilistes" pour réaliser la ville idéale d'Alexis ( maître du jeu et Product Owner).  une très bonne simulation de la mise en oeuvre de Scrum sur un projet qui illustre différentes problématiques : 

• estimation
• priorisation
• compréhension du besoin
• critères d'acceptation
• Scrum de Scrum avec deux équipes
• les itérations (on en a fait 3)
• la rétrospective

et j'en oublie certainement....

Merci aux organisateurs et au Cesi pour l'accueil.

J'ai pris deux photos postées sur Meetup.

Scrum Café bordelais du 14 Septembre 2011

Une 50aine de participants réunis dans un amphi de l'EPSI Bordeaux,

plusieurs Serious Games intéressants.

Pour entamer la session, Philippe Launay nous a donné des précisions sur la dernière mouture de Scrum (Juillet 2011).

Rien de révolutionnaire, mais quelques précisions intéressantes. Par exemple sur le contenu de la Backlog qui devient ordonnée et non pas priorisée. Le plan de release a également disparu...

Pour en savoir plus, je vous renvoie vers le site de Fabrice Aimetti "Agilarium.fr"

NDLR : dans le cas d'une réécriture iso-fonctionnelle, tout (ou presque) est en effet aussi important, mais il faut bien commencer quelque part.

Je retiens surtout pour l'animation des ateliers la présence d'un observateur par équipe. Lorsque c'est bien fait, l'observateur apporte beaucoup de choses sur le déroulement de l'atelier et sur l' "auto-organisation" des équipes.

La session a duré un peu en longueur, succès oblige!

Bon je reviens à la prochaine session, j'ai une bonne marge de progression...