Quand écririez-vous un cas d'utilisation plutôt qu'une user story ?

Utilisez les stories quand l'équipe peut se parler et affiner au fil de l'eau. Les cas d'utilisation conviennent aux flux complexes, aux nombreux chemins alternatifs, ou à une documentation qui doit tenir seule pour des auditeurs, un prestataire ou une équipe difficile à joindre. Un cas d'utilisation capture toute l'interaction, y compris les flux d'exception ; une story est un marque-page pour une conversation, et elle échoue quand cette conversation ne peut pas avoir lieu.

Ça dépend de si la conversation peut avoir lieu. Les stories marchent très bien quand l'équipe est ensemble et peut affiner au fil de l'eau, parce que la story n'est en réalité qu'une promesse d'en parler. Dès que cette conversation devient coûteuse, le format cesse de fonctionner. Donc sur un projet où la réalisation était confiée à un prestataire dans un autre fuseau horaire et où le contrat référençait la spécification, j'ai écrit des cas d'utilisation, parce que le document devait répondre aux questions tout seul sans moi dans la pièce. Pareil sur tout ce qui implique un régulateur, où il faut que les flux alternatifs et d'exception soient écrits et traçables plutôt qu'actés oralement en session d'affinage. J'ai aussi mélangé, avec des cas d'utilisation pour les deux flux réellement compliqués, comme un rapprochement de paiements avec environ neuf chemins d'exception, et des stories pour tout le reste. Choisir un seul format pour tout le projet parce que c'est la règle maison, c'est comme ça qu'on obtient soit de la surcharge, soit des trous.