story

Des exemples de story

Des exemples de story

Marie et Bob racontent à Pierre une story qui les concerne dans PermaBio

L’agilité a popularisé la notion de story. On dit aussi user story ou US dans les équipes. Mais si on donne la définition usuelle :

Une story est un petit morceau de fonctionnalité qui apporte de la valeur à quelqu’un et qui est développé en un sprint

cela reste encore abstrait et ce qui dit Pierre.

DÉCOMPOSE la story

DÉCOMPOSE la story

Je m'amuse à trouver des noms parlants ou des acronymes faciles à retenir pour désigner les patterns que je mets en évidence dans la 5e édition de mon livre Scrum. Je suis content du dernier que je viens de trouver

Après les 6D, ADAPTER, PROUVÉ, voici DÉCOMPOSE, le pattern qui donne des pistes pour décomposer une story. Ce pattern propose 9 axes de réflexion pour une possible décomposition d’une story : D comme données, on décompose avec d’abord une story qui traite un sous-ensemble de données É comme étape d’un workflow, une story pour chaque étape C comme cas nominal, on fait une première story pour juste le cas de succès O comme opérations, une story pour chaque opération élémentaire M comme métier, une première story ne prend pas en compte toutes les règles métier P comme performance, on fait d’abord une story qui marche puis on optimise la performance dans une seconde O comme option, on réalise d’abord la story avec une IHM basique, l’option plus évoluée sera dans une autre story S comme spike, on explore d’abord des solutions possibles, puis un autre story permettra de réaliser avec la solution choisie E (bon, sans accent) comme étude de l’impact, ce que fait la première story (très simple) qui sert à valider (ou pas) une hypothèse auprès des utilisateurs
La vie de la story selon Elodie

La vie de la story selon Elodie

Merci Élodie

Après Jimmy, c"est Élodie qui a commenté mon billet la vie de la story. Elle me fait des remarques très intéressantes, j’y réponds en dessous, dans un ordre revu. Élodie : J’imagine que c’est une simplification, un workflow idéal… mais il donne impression que toute idée aboutira… je serais plus à l’aise avec quelques “portes de sortie” pour prendre en compte les depriorisations, les risques, les imprévus… Dans une autre vie, il y a plus de 15 ans, j’ai fait de la modélisation de processus en UML ou BPMN, il y avait plein de branches et de boucles… L’agilité m’a appris à simplifier.

La vie de la story selon Jimmy

Merci Jimmy pour le feedback

Suite à mon article d’hier, j’ai reçu un commentaire de Jimmy L. que je remercie de son feedback. Jimmy est tout à fait d’accord avec moi pour ne montrer à la revue qu’une story déjà déclarée finie. Cependant il enchaîne : …Mais cela m’étonne justement qu’on s’arrête généralement à “Finie” sur ce genre de workflow, et qu’on ne mette pas au moins en bout l’état correspondant à l’avis positif reçu en revue de sprint.
La vie de la story a changé en 10 ans

La vie de la story a changé en 10 ans

Une évolution sensible vers du flux

Il y a à peu près 10 ans, j’écrivais un billet “Les états significatifs d’un élément de backlog”. Amusant de le relire aujourd’hui et de constater comment mon approche de Scrum a —légèrement— évolué au fil des ans. Pas beaucoup sur les états, car je décris toujours la vie d’une story avec cinq états, dont les noms ont un peu changé, mais pas les 2 essentiels : prêt et fini.
Exprimer et formaliser le besoin

Exprimer et formaliser le besoin

Tout savoir pour arriver à un beau backlog

Le Cube à emporter de 1CUBE&GO, que j’anime à Toulouse le 13 décembre, s’intitule Exprimer et formaliser le besoin Il est destiné à toutes les personnes qui s’intéressent à découvrir, faire émerger, comprendre, analyser, transmettre et développer le “besoin” pour en faire le bon produit. Il présente une approche pratique qui a maintenant fait ses preuves. Elle est décrite dans les chapitres 14 et 15 de mon livre Scrum, qui pourra être utilisé en complément du Cube :
Les 6 activités de l'affinage du backlog

Les 6 activités de l'affinage du backlog

Un nouveau chapitre consacré à l'affinage dans l'édition 4 de Scrum

Il y a tout juste un an, je consacrais beaucoup de mon temps à l’écriture de Scrum#4. Des efforts récompensés, cette nouvelle édition a finalement été publiée en octobre et, depuis, elle s’écoule bien : nous avons dépassé les 2000 exemplaires en mai et elle est toujours bien classée chez Amazon. L’édition 4 comporte de nombreuses nouveautés. En particulier, apparait un chapitre dédié à l’affinage du backlog. Le schéma présente les activités d’affinage.

Une après-midi révélatrice de ScrumMaster

Dans l’édition 4 de mon livre, j’ai ajouté des histoires pour raconter une journée typique d’un ScrumMaster et d’un Product Owner. Voici la deuxième partie avec un extrait tiré du chapitre 5 Le rôle du ScrumMaster. Nous avions laissé Nicolas, qui tient ce rôle dans l’équipe Peetic (le site de rencontres pour animaux de compagnie), au bord du canal, pour une séance de jogging, après une belle matinée de ScrumMaster.
La vie d'une story

La vie d'une story

Après les 6D, les 6C

Dans mon livre Scrum, chapitre Structurer le backlog, page 74, je présente le workflow de la story. Extraits : En 2001, Ron Jeffries définissait la vie de la story avec trois phases : la carte comme moyen de l’identifier, puis une conversation et enfin une confirmation. Cela est connu comme les « 3C » . En fait, avec Scrum, l’équipe déroule deux cycles de conversation et confirmation : un premier pour obtenir une story prête, un second pour qu’elle soit finie.
Décider qu'une story est prête

Décider qu'une story est prête

Les 6D pour aider à la décision

Début juin 2015, en pleine écriture de mon livre, je n’avais encore que 4D et demi. Dans l’édition 4, il y a bien les 6, pages 82 et 83, chapitre Affiner le backlog. Voici l’extrait qui en cause : C’est l’équipe qui décide si une story est prête. Pour prendre sa décision, elle pourra s’appuyer sur une liste de vérifications, la définition de prêt. La définition de prêt est élaborée par l’équipe et dépend du contexte.
Glossaire R-S

Glossaire R-S

Dans l’édition 4 de mon livre, j’ai ajouté un glossaire. C’est une des nombreuses nouveautés. Le glossaire donne le sens que je donne pour ces termes que j’emploie dans le livre. Il est situé à la fin, entre le quiz et l’index. Je l’ai voulu assez court (il y a 70 entrées) et avec des définitions brèves. Voici les entrées pour les lettres R et S : Raid Agile : une formation différente qui vous fournit les outils et surtout la culture, la clé pour accélérer votre transformation agile.
Le story mapping, ma préface

Le story mapping, ma préface

Le livre de Jeff Patton a été traduit pour une publication chez Dunod

En français, le titre est simplement “Le story mapping”. J’ai participé à la relecture du texte traduit et j’ai eu le plaisir d’écrire la préface pour l’édition française. Voici la première partie. Je n’ai jamais rencontré Jeff Patton. Je ne sais même pas s’il est de la famille du général. Mais je l’aime bien. Ce n’est pas parce que j’ai échangé quelques tweets et mails avec lui, car cela ne remplace pas une conversation directe, ce que vous comprendrez comme jamais en lisant cet ouvrage.
Définition de fini multi-niveaux

Définition de fini multi-niveaux

Douze cases pour placer chaque élément de la définition de fini

La définition de fini est le plus souvent une simple liste. Pour être plus pertinent, on peut définir plusieurs niveaux de fini, et pour être plus complet, plusieurs aspects de la finition. Cette présentation avec 4 cercles concentriques et 3 zones permet d’élaborer collectivement une définition de fini avec bien plus de subtilité qu’une simple liste. Niveaux hiérarchiques fini pour une story fini pour une feature : tout ce qu’il faut vérifier sur une feature qui ne l’a pas été sur ses stories fini pour le sprint : tout ce qu’il faut vérifier sur l’incrément de sprint et qui n’a pas été vérifié sur les stories et les features fini pour la release : tout ce qui n’est pas fait à chaque sprint et qui reste à faire à la fin La définition de story est vivante : au cours de sprints, un contrôle peut changer de niveau.
Le workflow d'une story

Le workflow d'une story

Les 5 C

Dans « Extreme Programming Installed », Ron Jeffries, en 2001, définit la vie de la story avec trois phases : la carte comme moyen de l’identifier, puis une conversation et enfin une confirmation. Cela est connu comme les « 3C »[1]. En fait, l’équipe déroule deux cycles de conversation et confirmation : un premier pour obtenir une story prête, un second pour que la story soit finie, donc nous avons les « 5C » :

Investir dans des stories prêtes

Un bon acronyme est celui qui dure longtemps

C’est le cas de INVEST, lancé en 2003 par Bill Wake. Cela fait donc 12 ans et INVEST est encore populaire ; des ouvrages récents y font toujours référence (je pense à No Estimates). Si l’acronyme est bon, je n’ai jamais trouvé cette liste de caractéristiques d’une bonne story particulièrement percutante. Je ne crois pas avoir fait de référence à INVEST ni dans mon blog ni dans mon livre. Bonne à quoi, la story ?
Les participants à l’affinage de backlog

Les participants à l’affinage de backlog

L'affinage consiste, à partir de l'idée brute, à rendre une story prête à être réalisée en un sprint

Dans la série sur l'affinage du backlog, après avoir vu le pourquoi, le quand et le quoi, voyons le qui. Bien évidemment en premier lieu vient le Product Owner. C’est lui le principal affineur. Il affine pendant le MAB, mais aussi en dehors, car il peut faire seul des travaux d’affinage comme : approvisionner à partir du bac à sable, revoir l’ordre du bac d’affinage, purger les bacs. Pour les autres travaux, il s’appuiera volontiers sur des membres de l’équipe ou des parties-prenantes spécialistes du domaine (des experts du sujet).