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 c’est ce que dit Pierre.

Structurer le backlog

Structurer le backlog

Chapitre 6 : le backlog, avec une vue statique ou structurelle

On dit backlog et non pas black dog (référence à Led Zeppelin)

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 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.
Planifier pour réussir le sprint

Planifier pour réussir le sprint

C'est la story qui sprinte

En parcourant mon livre à la recherche du 6e D, je m’arrête par hasard sur les pages 108 et 109. Et là, je constate que les titres des paragraphes 9.1 et 9.2 sont quasiment identiques, à l’article près. Évidemment ce n’est pas ce que j’ai voulu. C’est un bug. Je mène l’enquête et découvre rapidement que le bon titre du §9.1 est “Planifier pour réussir le sprint”. D’ailleurs ce titre était déjà présent dans l’édition 3 et il apparaît dans les fichiers que j’ai conservés pour la fabrication de l’édition 4.
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. Une façon simple pour démarrer est de se baser sur 6 caractéristiques de la story, les « 6D ».

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 » :