5 signes indiquant que vos user stories ne sont pas terribles : Différence entre versions

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
 
Ligne 12 : Ligne 12 :
 
{| class="captionBox" style="float: left"
 
{| class="captionBox" style="float: left"
 
| class="captionedImage" |
 
| class="captionedImage" |
[[Image:stop-ml.jpg|stop-ml.jpg]]
+
[[Image:stop-ml.jpg|stop-ml.jpg|link=]]
 
|-
 
|-
 
| class="imageCaption" | http://www.flickr.com/photos/arlette/3260468/
 
| class="imageCaption" | http://www.flickr.com/photos/arlette/3260468/
 
|}
 
|}
 
Il y a environ un an et demi</span>, <span class="hps">j'ai écrit un article sur la façon de [http://blog.scrumphony.com/2011/09/5-signs-that-your-user-stories-suck/ rater vos user stories]. Depuis</span>, j'ai vu <span class="hps">d'autres</span> <span class="hps atn">"</span>User Stories" <span class="hps">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...</span></span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''<span class="hps">1 - VOS USER STORIES NE SONT QUE DES EMBALLAGES</span>'''<br /> <br /> <span class="hps">Si vos user stories ne sont uniquement constituées</span> que <span class="hps atn">d'</span>une seule tâche, <span class="hps">c'est le signe que vous les utilisez juste comme un emballage. Je ne sais pas pourquoi, mais il semble que certaines personnes croient </span>qu'elles doivent <span class="hps">utiliser le format de user story pour tout. Une user story</span><span class="hps atn"> est "</span>la promesse <span class="hps">d'une conversation</span>". <span class="hps">S'il n'y a rien à discuter et que c'est une simple tâche</span>, alors <span class="hps">é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.</span><br /> <br /> '''<span class="hps">2 - VOS USER STORIES PEUVENT ETRE TERMINÉES EN MOINS D'UN JOUR</span>'''<br /> <br /> <span style="display: block; text-align: justify"><span class="hps">Si vous avez plus de 40 user stories dans votre Backlog de Sprint</span>, il <span class="hps">devient vraiment difficile d'obtenir un engagement de votre équipe. Certaines personnes pourraient me dire </span>: <span class="hps">"Attendez, c'est pas génial que l'équipe ait été capable de créer ces petites stories </span>?". <span class="hps">Si, c'est génial, mais pas si toutes ces stories sont des tâches</span>. <span class="hps">Dans ce cas</span>, ces stories <span class="hps">appartiennent à une plus grande story et n'ont en fait pas de sens lorsqu'on les prend une par une</span>. <span class="hps">Vérifiez si vos stories sont bien destinées à ajouter de nouvelles fonctionnalités</span>, s'il n'y a pas <span class="hps">quelque chose qui cloche.</span></span></span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''<span style="display: block; text-align: justify"><span class="hps">3 - VOTRE USER STORY NE DECRIT PAS UNE FEATURE</span></span>'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify"><span class="hps">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é</span>, quelque chose <span class="hps">s'est mal passée. J'ai vu des PO écrirent des stories qui décrivaient des choses comme "Ecrire le document </span><span class="hps atn">X" ou "</span>Créer le <span class="hps">test d'acceptation Y"</span>. <span class="hps">Dans ce cas, je demande le [http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod DoD] à l'équipe, parce que ces choses devraient clairement y figurer. Et si vous ne voulez pas les ajouter au DoD</span>, créez une tâche, mais ne <span class="hps">tordez pas le format de la user story.</span></span></span><span style="display: block; text-align: justify"><br /> '''<span class="hps">4</span> <span class="hps atn">- VOUS L'UTILISEZ POUR TOUT</span>'''<br /> <br /> <span class="hps">C'est formidable que</span> <span class="hps atn">vous ayez décidé d'</span>utiliser des user stories pour<span class="hps"> créer votre backlog. Mais vous savez quoi </span>? Vous pouvez <span class="hps">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</span>. <span class="hps">Dans beaucoup de cas, cela n'a tout simplement aucun sens</span>, <span class="hps">par exemple lorsque vous voulez ajouter des exigences non fonctionnelles</span>. <span class="hps">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</span>, créez une epic et <span class="hps">ajoutez-la. Mais s'il vous plaît</span>, n'utilisez pas <span class="hps">le format de la user story pour tout ce qui est dans votre backlog</span>.<br /> <br /> '''<span class="hps">5 - VOUS AVEZ PERDU VOTRE UTILISATEUR</span>'''<br /> <br /> <span class="hps">Avez-vous écrit des stories qui commencent par </span>: <span class="hps">"En tant que chef de projet</span><span class="hps atn">...", "En tant que </span><span class="hps">chef produit..."</span><span class="atn">, "</span>En tant que développeur<span class="hps atn">..." ou "</span>En tant que <span class="hps">testeur" </span>? Dans lesquelles vous avez en fait <span class="hps">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 [http://www.infoq.com/presentations/pragmatic-personas personas]</span>. <span class="hps">Mais concentrez-vous toujours sur votre utilisateur final.</span><br /> <br /> <span class="hps">Je suis impatient de recevoir vos commentaires</span>. <span class="hps">Quels signes avez-vous observé </span>?<br /> </span>
 
Il y a environ un an et demi</span>, <span class="hps">j'ai écrit un article sur la façon de [http://blog.scrumphony.com/2011/09/5-signs-that-your-user-stories-suck/ rater vos user stories]. Depuis</span>, j'ai vu <span class="hps">d'autres</span> <span class="hps atn">"</span>User Stories" <span class="hps">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...</span></span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''<span class="hps">1 - VOS USER STORIES NE SONT QUE DES EMBALLAGES</span>'''<br /> <br /> <span class="hps">Si vos user stories ne sont uniquement constituées</span> que <span class="hps atn">d'</span>une seule tâche, <span class="hps">c'est le signe que vous les utilisez juste comme un emballage. Je ne sais pas pourquoi, mais il semble que certaines personnes croient </span>qu'elles doivent <span class="hps">utiliser le format de user story pour tout. Une user story</span><span class="hps atn"> est "</span>la promesse <span class="hps">d'une conversation</span>". <span class="hps">S'il n'y a rien à discuter et que c'est une simple tâche</span>, alors <span class="hps">é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.</span><br /> <br /> '''<span class="hps">2 - VOS USER STORIES PEUVENT ETRE TERMINÉES EN MOINS D'UN JOUR</span>'''<br /> <br /> <span style="display: block; text-align: justify"><span class="hps">Si vous avez plus de 40 user stories dans votre Backlog de Sprint</span>, il <span class="hps">devient vraiment difficile d'obtenir un engagement de votre équipe. Certaines personnes pourraient me dire </span>: <span class="hps">"Attendez, c'est pas génial que l'équipe ait été capable de créer ces petites stories </span>?". <span class="hps">Si, c'est génial, mais pas si toutes ces stories sont des tâches</span>. <span class="hps">Dans ce cas</span>, ces stories <span class="hps">appartiennent à une plus grande story et n'ont en fait pas de sens lorsqu'on les prend une par une</span>. <span class="hps">Vérifiez si vos stories sont bien destinées à ajouter de nouvelles fonctionnalités</span>, s'il n'y a pas <span class="hps">quelque chose qui cloche.</span></span></span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''<span style="display: block; text-align: justify"><span class="hps">3 - VOTRE USER STORY NE DECRIT PAS UNE FEATURE</span></span>'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify"><span class="hps">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é</span>, quelque chose <span class="hps">s'est mal passée. J'ai vu des PO écrirent des stories qui décrivaient des choses comme "Ecrire le document </span><span class="hps atn">X" ou "</span>Créer le <span class="hps">test d'acceptation Y"</span>. <span class="hps">Dans ce cas, je demande le [http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod DoD] à l'équipe, parce que ces choses devraient clairement y figurer. Et si vous ne voulez pas les ajouter au DoD</span>, créez une tâche, mais ne <span class="hps">tordez pas le format de la user story.</span></span></span><span style="display: block; text-align: justify"><br /> '''<span class="hps">4</span> <span class="hps atn">- VOUS L'UTILISEZ POUR TOUT</span>'''<br /> <br /> <span class="hps">C'est formidable que</span> <span class="hps atn">vous ayez décidé d'</span>utiliser des user stories pour<span class="hps"> créer votre backlog. Mais vous savez quoi </span>? Vous pouvez <span class="hps">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</span>. <span class="hps">Dans beaucoup de cas, cela n'a tout simplement aucun sens</span>, <span class="hps">par exemple lorsque vous voulez ajouter des exigences non fonctionnelles</span>. <span class="hps">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</span>, créez une epic et <span class="hps">ajoutez-la. Mais s'il vous plaît</span>, n'utilisez pas <span class="hps">le format de la user story pour tout ce qui est dans votre backlog</span>.<br /> <br /> '''<span class="hps">5 - VOUS AVEZ PERDU VOTRE UTILISATEUR</span>'''<br /> <br /> <span class="hps">Avez-vous écrit des stories qui commencent par </span>: <span class="hps">"En tant que chef de projet</span><span class="hps atn">...", "En tant que </span><span class="hps">chef produit..."</span><span class="atn">, "</span>En tant que développeur<span class="hps atn">..." ou "</span>En tant que <span class="hps">testeur" </span>? Dans lesquelles vous avez en fait <span class="hps">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 [http://www.infoq.com/presentations/pragmatic-personas personas]</span>. <span class="hps">Mais concentrez-vous toujours sur votre utilisateur final.</span><br /> <br /> <span class="hps">Je suis impatient de recevoir vos commentaires</span>. <span class="hps">Quels signes avez-vous observé </span>?<br /> </span>

Version actuelle datée du 13 avril 2021 à 14:14

Auteur : Marc Löffler
Source : 5 Signs That Your User Stories Suck
Date : 15/09/2011


Traducteur : Fabrice Aimetti
Date : 16/09/2011


Traduction :

stop-ml.jpg

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é ?