Existe-t-il un moyen standard de savoir quand arrêter d'écrire des user stories, et si oui, sur quelle base cela se base-t-il et comment cela s'applique-t-il aux futurs sprints?
Je ne connais pas personnellement de méthode standard en soi. Cela se résume vraiment à une combinaison de votre méthodologie et des attentes de vos clients.
J'ai constaté qu'il est préférable de commencer à coder dès que vous avez «suffisamment» d'histoires de votre client pour commencer. Comme d'autres l'ont dit, cela pourrait être pour une seule itération, mais cela pourrait l'être pour plus. Votre mesure de suffisamment devrait être guidée par la fréquence à laquelle vous avez l'intention de divulguer le code de travail à votre client, et plutôt que de demander à votre client de vous donner une liste interminable d'histoires (dont beaucoup ne seront probablement jamais réalisées, ou pourraient changer, ou ne pas changer). faites votre date limite de sortie majeure), il est préférable de demander à votre client les 3-5 premières fonctionnalités les plus importantes et les plus prioritaires. Lorsque ceux-ci sont terminés et communiqués à votre client, vous collectez les 3 à 5 fonctionnalités les plus importantes et ainsi de suite. Demandez plus ou moins selon la durée probable de vos itérations.
Votre client ou contrat ou date limite peut peut-être vous indiquer quand arrêter de demander des histoires, mais entre-temps, vous demandez des histoires et vous arrêtez aussi souvent que vous l'avez fait. Lorsque, d'un commun accord, vous et le client estimez que le produit est suffisamment complet, vous pouvez alors décider quoi faire avec les histoires restantes que le client ne vous a peut-être pas encore données.
Le principal avantage de cette approche est que vous finissez par fournir le plus de valeur au client dès le départ, et au fur et à mesure que le projet se développe et que le temps passe, la quantité de valeur que vous livrez au client diminue au point où le client peut faire un décision sur les "derniers 20% de fonctionnalités" qu'ils auraient pu souhaiter et qui pourraient ne jamais être réellement utilisées. Il réduit également le temps perdu sur les éléments triviaux et de faible priorité, remettant la responsabilité (et le stress) de prioriser et de planifier les itérations sur le client, et tout cela uniquement en fonction des besoins du client. Cela ne signifie pas cependant que vous ne devez pas fournir de conseils au client afin d'éviter des goulots d'étranglement de planification difficiles qui peuvent devenir apparents lorsque vous parlez des exigences avec le client.
Lisez le développement logiciel Lean de Poppendeicks si vous souhaitez une description plus détaillée de cette approche dans un contexte plus large.