Comment décomposer des User Stories

[Rémy Sanlaville]

Bonjour à tous,

Je viens de lire l'article suivant : Patterns for Splitting User Stories

Je trouve l'article très intéressant et qui aborde un sujet important.
Il me semble un bon support pour lancer une discussion par mail
ou lors d'un prochain atelier.

En fait, l'article amène plusieurs sujets/questions :

   - Comment déterminer qu'une user story a la bonne taille (pas trop large, ni trop petite) ?

   - Comment faire pour découper une user story trop importante ?

   - Comment définir le bon niveau d'abstraction ? On se rend souvent compte qu'il y a une
palette assez importante entre trop de détails et trop abstrait et qu'il est difficile de savoir
où positionner correctement le curseur. Par exemple, pour certains le fait d'utiliser le
concept de panier dans un site web marchand permet de s'abstraire de la solution.
Pour d'autres, ce n'est pas suffisant et c'est trop bas niveau (cf. par exemple Step Away from the Tools).


Qu'en pensez-vous ?

Rémy

[Guillaume Berche]

Bonjour Rémy,

voici un retour d'expérience sur cette question. Nous avons souvent eu
de nombreux débats d'équipe sur cette question, et le bon équilibre
reste toujours difficile à conserver

> - Comment déterminer qu'une user story a la bonne taille (pas trop
> large, ni trop petite) ?

- pas trop petite: elle amene quand même une valeur métier en temps
que tel
- pas trop petite: son titre reste court, on se rappelle facilement à
quoi ca correspond (cohésion)
- pas trop petite: pas d'overlap avec les autres stories dans le
sprint, on peut les reordonner (~couplage)
- pas trop grosse: son estimation en points par l'équipe est plus
petite qu'une taille max convenu (20 pour nous)
- pas trop petite: on arrive à faire les revues de backlog/planning/
démos dans un temps correct (on s'y perd si trop de petites stories).

> - Comment faire pour découper une user story trop importante ?

Une des pratiques qui m'a été utile est de prévoir une section "Out Of
Scope" dans mon template de user-story. En préparant la story, et
ensuite en en discutant avec l'équipe et répondant aux questions, on y
déplace les points délicat/couteux/"avec moins de valeur" ou les
nouvelles idées pour les conserver pour les stories suivantes.

Sur les epics compliquées, je propose parfois une story de prototypage/
spike pour dégrossir le terrain et raffiner le champs du possible et
les specs (scénarios, mockups IHM). Ca nous permet aussi de murir la
reflexion dans le temps sans y avoir investi trop d'effort. Ca amène
des synergies avec les autres stories en cours (permet de rafiner
notre cible proche et oriente certains choix techniques).

Nous avons eu aussi parfois recours à un split par couches logicielles
(qui sont validées chacune par leur tests), typiquement retarder l'IHM
dans une deuxième story. Cependant les mockups IHM étaient souvent
prets des la 1er stories et les objects du domaines (et la couche
backend) étaient validés par des tests tests proches/identiques des
scenarios BDD appliqués sur l'IHM. La seconde story IHM utilisait
alors les tests du backend comme specs des interactions backend à
implémenter. Je le manie avec précaution, car ca peut retarder le
déploiement de la valeur vers l'utilisateur (augmenter le stock/
waste), mais parfois ca a été efficace pour nous.

Guillaume.

On Mar 5, 11:55 pm, Rémy Sanlaville <remy.sanlavi...@gmail.com> wrote:
> Bonjour à tous,
>
> Je viens de lire l'article suivant : Patterns for Splitting User

> Stories<http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-use...>

>
> Je trouve l'article très intéressant et qui aborde un sujet important.
> Il me semble un bon support pour lancer une discussion par mail
> ou lors d'un prochain atelier.
>
> En fait, l'article amène plusieurs sujets/questions :
>
>    - Comment déterminer qu'une user story a la bonne taille (pas trop
> large, ni trop petite) ?
>
>    - Comment faire pour découper une user story trop importante ?
>
>    - Comment définir le bon niveau d'abstraction ? On se rend souvent
> compte qu'il y a une
> palette assez importante entre trop de détails et trop abstrait et qu'il
> est difficile de savoir
> où positionner correctement le curseur. Par exemple, pour certains le fait
> d'utiliser le
> concept de panier dans un site web marchand permet de s'abstraire de la
> solution.
> Pour d'autres, ce n'est pas suffisant et c'est trop bas niveau (cf. par

> exemple Step Away from the Tools<http://sirenian.livejournal.com/71439.html>
> ).