Esiste un modo standard per sapere quando smettere di scrivere le storie degli utenti e, in caso affermativo, quali sono le basi per questo e come si applica agli sprint futuri?
Non conosco personalmente un metodo standard in sé. Dipende davvero da una combinazione della tua metodologia e delle aspettative dei tuoi clienti.
Ho scoperto che è meglio iniziare a scrivere codice non appena hai storie "sufficienti" da parte del tuo cliente per iniziare. Come altri hanno già detto, questo potrebbe essere per una singola iterazione, tuttavia potrebbe esserlo per altro. La tua misura di abbastanza dovrebbe essere guidata dalla frequenza con cui intendi rilasciare il codice funzionante al tuo cliente, e piuttosto che il tuo cliente ti dia e un elenco infinito di storie (molte delle quali probabilmente non verranno mai eseguite o potrebbero cambiare o potrebbero non essere fissare il termine ultimo di rilascio), è meglio chiedere al cliente le prime 3-5 funzionalità più importanti e con la massima priorità. Al termine, quando vengono rilasciati al cliente, vengono raccolte le 3-5 funzioni più importanti e così via. Chiedi di più o di meno a seconda della durata delle tue iterazioni.
Il cliente o il contratto o la scadenza potrebbero forse guidarti su quando smettere effettivamente di chiedere storie, ma nel frattempo hai chiesto storie e ti sei fermato tutte le volte che hai avuto iterazioni. Quando, previo accordo, tu e il cliente ritenete che il prodotto sia abbastanza completo, potete decidere cosa fare con le storie lasciate che il cliente potrebbe non avervi ancora dato.
Il vantaggio principale di questo approccio è che si finisce per fornire il massimo valore al cliente in anticipo, e man mano che il progetto cresce e il tempo passa, la quantità di valore che si sta offrendo al cliente diminuisce al punto in cui il cliente può fare un decisione in merito all '"ultimo 20% delle funzionalità" che avrebbero potuto desiderare e che non potrebbero mai essere effettivamente utilizzate. Riduce inoltre il tempo sprecato in articoli banali e di bassa priorità, rimettendo la responsabilità (e lo stress) di stabilire le priorità e pianificare le iterazioni sul cliente, e tutto basato esclusivamente sulle sue esigenze. Ciò non significa, tuttavia, che non si debba fornire una guida al cliente al fine di evitare difficili colli di bottiglia nella pianificazione che possono diventare evidenti quando si parla di esigenze con il cliente.
Leggi lo sviluppo del software Lean di Poppendeicks se desideri una descrizione più dettagliata di questo approccio in un contesto più ampio.