Story

Une story est un élément du backlog, morceau de fonctionnalité qui apporte de la valeur à quelqu’un. Avec cette définition, tout est story dans le backlog. À côté des stories qui apportent de la valeur aux utilisateurs (user story), cela conduit à avoir des stories pour apprendre et des stories d’investissement.

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.

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

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.

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.

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.

Il y a tout juste un an, je consacrais beaucoup de mon temps à l’écriture de Scrum édition 4. Des efforts récompensés, cette nouvelle édition a finalement été publiée en octobre et, depuis, elle s’écoule bien :

Dans l’édition 4 de mon livre, j’ai ajouté des histoires pour raconter une journée typique d’un Scrum Master et d’un Product Owner. On commence par la celle de Nicolas, le Scrum Master chez Peetic. Voici l’extrait tiré du chapitre 5 Le rôle du ScrumMaster. J’y ai ajouté, pour ce billet, des notes qui renvoient aux pratiques évoquées.

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ébut juin 2015, en pleine écriture de mon livre Scrum, 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 ».

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.

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

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).

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.

Le chapitre 14 de mon livre Scrum s’appelle “La story et ses tests d’acceptation”. Dans cette nouvelle édition, le titre a légèrement changé, car le chapitre inclut désormais la présentation des stories. Il a été presque entièrement réécrit, notamment pour incorporer des nouveaux outils du Product Owner, comme ceux que j’ai présentés le mois dernier lors du ScrumDay 2014.

Les notions manipulées pour aller de la vision à la story, avec quelques techniques de définition de produit pour y arriver. Ce quadrant montre 5 outils et 6 concepts situés dans 4 cases.

J’avais entendu parler du PODojo, atelier destiné aux Product Owners pour s’améliorer par la pratique. Le PODojo est au PO ce que les coding dojos sont aux développeurs. Il s’en était déroulé quelques uns lors des conférences agiles l’an dernier.

Une story est prête à prendre le départ du sprint si son comportement attendu (conditions d’acceptation) et la qualité requise (critères de finition) sont suffisamment connus de l’équipe. Un autre volet essentiel pour s’assurer de la capacité de l’équipe à développer la story pendant le sprint porte sur les conditions de réalisation. Qu’y a t-il dans la définition de prêt d’une story ?

J’ai arrêté mon sondage sur les estimations à 100 réponses, c’est plus facile pour calculer les pourcentages. Voici les résultats.

Agile tour Toulouse a lieu jeudi à Diagora Labège. J’y présenterai à 10h30 en salle B2 une session sur “la culture du backlog”. La culture dont il est question ici est plutôt de l’agriculture, dans le sens faire pousser les idées semées jusqu’à ce qu’elles soient des stories prêtes à prendre le départ du sprint. Je préfère dire cultiver son backlog, plutôt que groomer comme dit une de mes équipes, ou même raffiner1.