Sculptez vos user stories et critères d’acceptance à l’aide de questions

5047534162_4332d7305d_z

Une idée de fonctionnalité est comme un matériau brut que l’on peut s’amuser à sculpter. Je l’ai remarqué lors d’ateliers en questionnant les équipes que j’accompagne sur les fonctionnalités qu’elles veulent développer et la manière dont elles comptent les valider. J’utilise les trames “User story” et BDD (Behaviour Driven Development) pour capturer l’essence du besoin et la manière dont la réponse pourra être observée une fois la fonctionnalité développée. Je trouve beaucoup de valeur à ce type d’atelier car, d’une part, il permet aux équipes de se former aux user stories et aux scénarios BDD en utilisant leur propres sujets et d’autre part, de s’imprégner du format de l’atelier qu’elles peuvent réutiliser.
Lire la suite

3 manières de découper ses user stories

Slices

S’intéresser à la taille de ses user stories et les découper lorsqu’elles sont trop grandes est une bonne pratique. Cela permet d’éviter l’effet tunnel, de produire de la valeur rapidement et de contribuer à une meilleure organisation du travail de tout le monde. Encore faut-il les découper efficacement afin qu’elles soient testables et créent de la valeur. Lire la suite

La User Story du myope

Taupe myope

Le cycle de vie d’une User Story l’amène a être écrite sur une carte et affichée sur divers murs, tableaux… Telle une bête de foire, votre histoire est amenée à être montrée à de nombreuses personnes ayant des vues plus ou moins bonnes, à des distances plus ou moins grandes.

Cet article parle de cette Story.

Watch

Un petit quart d’heure de lecture

Lire la suite

User Story : technique or not technique ?

Un récent billet de Pablo Pernot (Pourquoi une « user story » technique est un aveu d’échec) a soulevé quelques débats dans la communauté agile.

J’ai l’impression que la discussion est partie (un peu vite, c’est l’effet twitter) sur de mauvaises bases et que c’est pour ça que personne n’est d’accord. En fait plusieurs personnes ont raison mais elles ne parlent pas de la même chose.

Lire la suite

Vis ma vie de responsable QA (Part II) – Test Cases, ATDD et BDD

Chose promise chose due, voici la seconde partie de mon retour d’expérience QA sur l’ATDD, la BDD et les Tests Cases.

Selon moi une bonne US se doit d’être INVEST dans son descriptif:

I – Independent – La User Story ne doit pas être relative à une autre
N – Negotiable – Elle peut être négociée avec l’équipe
V – Valuable – Elle apporte de la valeur pour le client
E – Estimable – Elle est estimable par l’équipe (point ou jour homme)
S – Small – La tâche doit être la plus petite possible
T – Testable – Elle doit être testable et disposer de critères d’acceptation

Elle doit disposer de règles de gestion claires et si possible (est-ce possible?) exhaustives.
Enfin autant de cas de tests possible pour permettre au développeur de connaître et envisager tous les tenants et aboutissants de son développement. Lire la suite