Le Po de mon client rédige ses US sous la forme « en tant que PO » je veux que " la fonctionnalité X" soit déployée sur mon site web « à fin de l’utiliser »
Après relecture la plupart des US ne sont pas des US mais des Epics ( chacune d’entre elles est en fait un regroupement d’US), exemple concret :
En tant que PO, je veux disposer d’un header sur mon site de e-commerce utilisant le template XYZ, de manière à pouvoir l’utiliser à :
me connecter à l’espace client
accéder au panier
accéder au menu de navigation
revenir à la page d’accueil du site
Critère d’acceptation :
il est possible de se connecter à l’espace client
Il est possible d’accéder au panier
il est possible d’accéder au menu de navigation
il est possible de revenir à la page d’accueil du site
Il est clair que dans ce cas les US sont loin du critère INVEST…
Dois je lui proposer un atelier de réécriture des US ? de revoir la hiérarchie des taches ? de recentrer les US sur le USER ( c’est pas le PO…) ?
Je sais que je ne réponds pas à la question et je m’en excuse par avance, mais c’est tout sauf des US ou des Epics tout ça. Au mieux, c’est des use cases, mais ça demande une formalisation particulière et réponds à des enjeux qui ne sont pas les même.
Sans avoir le contexte, j’essaierai de savoir si les pré-requis sont présents pour qu’elle fasse ce que tu attends d’elle en tant que PO.
Je commencerai par comprendre ce que ses manageurs attendent d’elle.
Et aussi, ce qu’elle attend des Développeurs.
Ensuite, il faudrait comprendre son périmètre de décision. A-t-elle la pouvoir de décision sur la stratégie du produit ? A-t-elle accès aux utilisateurs finaux ?
Si elle est juste un maillon de la chaîne alors son comportement est relativement normal.
Il se peut qu’elle connait déjà la « théorie », mais ne peut pas l’appliquer.
Son contexte est-il favorable ?
Qu’est-ce qui selon toi l’empêche de faire ce que tu attends d’elle en tant que PO ?
Alors, ce n’est pas une user story car ce n’est pas orienté utilisateur, les critères d’acceptation sont inutiles, c’est trop gros, c’est pas précis, je pense que l’on est tous d’accord
Après, ça reste un besoin, et ça reste quelque chose à développer
Du coup que pensent les développeurs de ça ? Est-ce qu’il peuvent avancer avec ça ? Savent-ils où aller ?
Ce que je veux dire c’est que ce qui prime avant la forme, c’est la façon dont les gens communiquent, échangent, rendent le travail transparent pour tout le monde.
Si à la fin d’un sprint planning, on en vient de manière collaborative et intelligente à établir un plan pour le sprint qui émerge de ses US avec une direction claire pour chaque coéquipier, ben pourquoi pas, même si le sprint planning risque d’être épique (j’imagine aussi que vue l’US, il ne doit pas y avoir d’ateliers d’affinage)
Il est sûr que si le sprint part avec ce PBI, le résultat va être assez aléatoire, et peut-être devras-tu saisir l’opportunité d’un échec pour proposer à la PO de revoir la façon dont elle amène les sujets, les oriente, les découpent…
J’y vois effectivement plein de cas d’usage dans cette description, donc il y a manière à découper.
Ensuite, oui, l’utilisateur de l’application ne sera pas le PO, mais cela n’empêche pas que le PO teste les fonctionnalités qui seront développées… donc En tant que PO à modifier à En tant qu’utilisateur du site internet (prévoyez des personas pour les différents rôles possibles)…
En tout cas, manque de découpage certain à mon point de vue…et il manque le « afin de » car pourquoi vouloir revenir sur la page d’accueil, pourquoi accéder au panier, pourquoi se connecter, pourquoi accéder au menu de navigation… les devs n’y verront pas grand chose d’utile avec le contenu tel qu’il est rédigé ici… et avec un seul ticket fourre-tout, le moindre blocage et ton ticket n’avance plus… mais ça, vous devriez l’identifier rapidement lors du refinement… et donc, retour PO pour découper…
Ce que tu évoques, c’est exactement pourquoi je préfère les use case. Tu verras jamais un utilisateur dire « moi mon but, c’est d’accéder à mon panier ». Pourtant, c’est une fonctionnalité de l’application. Et tu te trouves dans une zone grise où tu ne sais pas comment documenter ce genre de choses (avec tous les cas d’erreurs et alternatifs qui peuvent venir avec) parce qu’on est dans l’angle mort de l’orientation centrée utilisateur.
yes tout à fait d’accord… la guerre US UC sera toujours là… l’essentiel étant qu’à la fin le produit évolue et apporte de la valeur à l’utilisateur
Je pense qu’il y a du Jira là-dessous et que ça déteint forcément dans les discussions…
Oulah, tu vois une guerre toi ? D’après mes observations, l’UC a été complètement crucifiée par les US au point que je connais très peu de monde autour de moi connaissant l’outil, si ce n’est personne.
J’oppose pas forcément, mais je constate simplement l’omniprésence de l’un et la quasi absence de l’autre. Ceci dit, ils sont effectivement complémentaire dans mon approche personnelle.
il y a des sujets où clairement les use-cases sont supérieurs à la user story, je pense notamment quand les actions de l’utilisateur ont des impacts sur des systèmes externes, ou qu’il y a pas mal de scénarios alternatifs à gérer
Mon plus gros problème vis à vis des User Story « comme expliquées dans XP », c’est que la littérature dit que la source des spécifications fonctionnels est le client (et par là, on pense plutôt à un groupe) et ne formalise donc nul part une quelconque documentation, assumant que le client sera toujours sur site, disponible et bien formé à l’exercice. La seule formalisation qu’on en retire sont les critères d’acceptances, mais entre les deux, c’est le grand flou.
D’après mes observations, l’UC a été complètement crucifiée par les US au point que je connais très peu de monde autour de moi connaissant l’outil, si ce n’est personne.