Come faresti realizzare tutte le tue aspettative all'interno di un utente?

Penso che sia sbagliato dividere la user-story in 3 parti. Hai detto che ogni comando dovrebbe essere accessibile da 3 posti. Questo può essere pre-assunto nelle user story per i nuovi comandi (o menzionati esplicitamente in ogni user story).

Se è necessario dividerlo perché lo sviluppo implementerà quelli come attività separate, IMO qualcosa non è progettato bene nel back-end.

Una trama utente di solito rappresenta una funzionalità completa. E non considererei la funzionalità completa a meno che il nuovo comando non sia accessibile da ogni luogo richiesto. Inoltre, includerei l'accessibilità nella stessa user story dello sviluppo dei comandi.

Per quanto riguarda il conseguimento della qualità richiesta, è per questo che viene effettuato il test.

Sono a conoscenza del fatto che in Agile, una storia utente deve essere completata e testata in un singolo sprint.

Con questo in mente, non inizierei a creare storie separate, ma semplicemente a crearne uno ea delineare i vari pezzi al suo interno.

Se dopo la stima (durante la pianificazione) è determinato che la storia si estenderà oltre un singolo sprint, dividerla in più con un genitore comune.

Che cosa pensa la tua squadra? Per alcune funzionalità, forse una singola storia andrà bene. Per altre funzioni più complicate, potresti aver bisogno di tre (o più) storie (Una per la riga di comando, una per l'interfaccia utente Web, una per Android, ecc.). Le storie non dovrebbero essere scritte nel vuoto, includere anche le persone che hanno una mentalità tecnica e il processo scorrerà molto più agevolmente. All'inizio di ogni iterazione, dedica un po 'di tempo a esaminare le storie con il team e ti faranno sapere se sono necessarie più storie o se ne va bene.

Non dare per scontato nulla per una storia, i requisiti di una storia eccessiva possono spesso essere trascurati, in conflitto con la storia o causare altre complicazioni. Trascorri il tuo tempo concentrandoti sull'esperienza dell'utente finale, idealmente crea casi di test / scenari per accompagnare la storia. Questo aiuterà il team a creare l'esperienza che desideri.

Per assicurare la qualità che ti fermi a visitare con il team, o ancora meglio sederti con il team per essere disponibile ogni volta che viene visualizzata una domanda. Più tempo si è in grado di trascorrere con il team, più si sarà soddisfatti della qualità. Non sto dicendo di microgestire ogni attività di minuto mai, ma piuttosto di essere disponibile man mano che le discussioni stanno avendo luogo e le domande vengono fuori. Chiedi di vedere il prodotto mentre è in fase di sviluppo, non aspettare una revisione o una vetrina di iterazione. Alla fine, Agile significa produrre un prodotto di qualità, ecco perché i principi 1 e 2 sono:

• Individui e interazioni su processi e strumenti
• Software di lavoro su documentazione completa

Cheers!