5 signes indiquant que vos user stories ne sont pas terribles
Auteur : Marc Löffler
Source : 5 Signs That Your User Stories Suck
Date : 15/09/2011
Traducteur : Fabrice Aimetti
Date : 16/09/2011
Traduction :
|
|
| http://www.flickr.com/photos/arlette/3260468/ |
Il y a environ un an et demi, j'ai écrit un article sur la façon de rater vos user stories. Depuis, j'ai vu d'autres "User Stories" qui m'ont donné la chair de poule. C'est pourquoi j'ai décidé d'écrire cet article. Donc, voici ma nouvelle liste de signes indiquant que vos user stories ne sont pas terribles...
1 - VOS USER STORIES NE SONT QUE DES EMBALLAGES
Si vos user stories ne sont uniquement constituées que d'une seule tâche, c'est le signe que vous les utilisez juste comme un emballage. Je ne sais pas pourquoi, mais il semble que certaines personnes croient qu'elles doivent utiliser le format de user story pour tout. Une user story est "la promesse d'une conversation". S'il n'y a rien à discuter et que c'est une simple tâche, alors écrivez la sous forme d'une tâche. Ne l'emballez pas avec un pseudo-utilisateur. Dans la plupart des cas, c'est aussi le signe que vos user stories sont trop petites.
2 - VOS USER STORIES PEUVENT ETRE TERMINÉES EN MOINS D'UN JOUR
Si vous avez plus de 40 user stories dans votre Backlog de Sprint, il devient vraiment difficile d'obtenir un engagement de votre équipe. Certaines personnes pourraient me dire : "Attendez, c'est pas génial que l'équipe ait été capable de créer ces petites stories ?". Si, c'est génial, mais pas si toutes ces stories sont des tâches. Dans ce cas, ces stories appartiennent à une plus grande story et n'ont en fait pas de sens lorsqu'on les prend une par une. Vérifiez si vos stories sont bien destinées à ajouter de nouvelles fonctionnalités, s'il n'y a pas quelque chose qui cloche.
3 - VOTRE USER STORY NE DECRIT PAS UNE FEATURE
C'est en partie lié aux points 1 et 2, car dans la plupart des cas, ces signes apparaissent ensemble. Si vos stories décrivent des tâches pour le développeur au lieu de décrire une nouvelle fonctionnalité, quelque chose s'est mal passée. J'ai vu des PO écrirent des stories qui décrivaient des choses comme "Ecrire le document X" ou "Créer le test d'acceptation Y". Dans ce cas, je demande le DoD à l'équipe, parce que ces choses devraient clairement y figurer. Et si vous ne voulez pas les ajouter au DoD, créez une tâche, mais ne tordez pas le format de la user story.
4 - VOUS L'UTILISEZ POUR TOUT
C'est formidable que vous ayez décidé d'utiliser des user stories pour créer votre backlog. Mais vous savez quoi ? Vous pouvez utiliser n'importe quel format, celui que vous souhaitez. Il n'existe aucune règle dans Scrum qui vous impose d'utiliser des user stories. Vous n'êtes pas obligé d'utiliser ce format pour tout ce qui est dans votre backlog. Dans beaucoup de cas, cela n'a tout simplement aucun sens, par exemple lorsque vous voulez ajouter des exigences non fonctionnelles. Ajoutez plutôt ces exigences non-fonctionnelles aux critères d'acceptation de vos user stories. Si elles s'appliquent à plus d'une user story, créez une epic et ajoutez-la. Mais s'il vous plaît, n'utilisez pas le format de la user story pour tout ce qui est dans votre backlog.
5 - VOUS AVEZ PERDU VOTRE UTILISATEUR
Avez-vous écrit des stories qui commencent par : "En tant que chef de projet...", "En tant que chef produit...", "En tant que développeur..." ou "En tant que testeur" ? Dans lesquelles vous avez en fait perdu l'utilisateur réel de votre logiciel. Ce ne seront pas le chef de projet ou le chef produit qui utiliseront votre logiciel. Recommencez et demandez-vous qui va l'utiliser et écrivez vos user stories en ayant en tête leur vision des choses. Une autre possibilité est de créer des personas. Mais concentrez-vous toujours sur votre utilisateur final.
Je suis impatient de recevoir vos commentaires. Quels signes avez-vous observé ?
