Discussion :

[kenji_getpowered]

Bonjour,

Je me pose une question sur la précision des backlogs produit. Je veux savoir si les contraintes fonctionnelles doivent apparaître dans les backlog de produits.
Par exemple : le logiciel doit faire du drag and drop d'objet entre plusieurs "zone". Mais certains objets ne peuvent pas être sur toutes les zones.
Un autre exemple bête serait les contraintes sur les champs de saisies de formulaire.

Où doivent se mettre ces contraintes?

[rad_hass]

Ce sont des scénarios de test d'interface dont tu as besoins, les critères d'acceptations me semble le choix le plus judicieux, mais à confirmer ;-)

En tout cas dans la description de l'User Story ces informations me semble déjà trop dans le détail ...

[kenji_getpowered]

scénarios de tests d'interfaces ou user story (de XP programming), je note... C'est pas quelque chose qui est noté dans Scrum.

Parceque c'est à prendre en compte dans l'estimation des charges.

[kenji_getpowered]

En même temps, j'aimerais voir comment ca se présente (je pense que je vais pouvoir en trouver sur le net - enfin j'espère) mais aussi je me pose des questions sur la précision de ces tests. Peuvent ils être vraiment exhaustif?

[apieum]

Ce sont des scénarios de test d'interface dont tu as besoins, les critères d'acceptations me semble le choix le plus judicieux, mais à confirmer ;-)

En tout cas dans la description de l'User Story ces informations me semble déjà trop dans le détail ...

Tu peux utiliser des technical stories (histoires techniques).
Dans certains cas, ça me parait tout à fait faisable, il doivent être dans le backlog de produit.

Mais les aspects techniques peuvent être intégrés le plus souvent dans les user story et les tests par exemple :
En tant que product owner je peux faire glisser les items du backlog qui ont été estimés vers les backlog de sprint afin de planifier une release.

Test1 :
Étant donné : le product owner suite à plusieurs réunions avec son équipe qui leur ont permis de définir la notion de fini, les fonctionnalités et un backlog initial, d'estimer toutes les stories du backlog, de définir la durée des sprints et estimer la capacité de l'équipe
quand : il fait glisser des stories vers les backlogs de sprint pour planifier une release
alors : les stories apparaissent dans les backlog de sprint et il peut visualiser le planning de la release ainsi que le cout total (quantité de travail) nécessaire à sa réalisation.

Test2 :
Étant donné : le product owner suite à plusieurs réunions avec son équipe qui leur ont permis de définir la notion de fini, les fonctionnalités et un backlog initial, d'estimer quelques stories du backlog, de définir la durée des sprints et estimer la capacité de l'équipe
quand : il fait glisser des stories non estimées vers les backlogs de sprint pour planifier une release
alors : les stories ne peuvent pas être déplacées et un message d'avertissement lui indique que cette opération n'est pas possible car elles ne sont pas estimées, les stories n'apparaissent donc pas dans le backlog de sprint et même s'il peut visualiser le plan de release celui-ci n'indique pas le cout exact nécessaire à sa réalisation.

Une story doit être réalisable au cours d'un sprint donc la taille idéale (et donc son détail) dépend du nombre de personnes dans l'équipe, de la capacité à la traiter au cours du sprint.
Si tu es seul (tu ne fais pas du scrum ), tu as intérêts de détailler tes stories,
au contraire si ton équipe est bien rodée et que la story se décompose facilement en tests et taches réalisables par plusieurs personnes, tu peux la garder à un niveau de détail grossier.