Devo scrivere una User story per un requisito che implica il passaggio dei filtri di ricerca allo stesso URI e il recupero dei risultati corrispondenti.
Ho 5 filtri.
Ho intenzione di scrivere 5 storie diverse di tipo: Come utente URI posso cercare per # filter1 in modo da poter recuperare i risultati basati su # filter1.
E poi una sesta storia che prevede la ricerca di uno o più o di tutti e sei i filtri insieme.
Questa è una strada sensata da prendere?
Se la mantieni come una singola user story e ottieni solo 4/5 filtri alla fine dello sprint, la tua singola storia è incompleta. Se lo dividi, se ottieni 4/5 filtri completi, 4 di 5 piani possono essere contrassegnati come completati.
Quando ottengo storie come questa, che hanno caratteristiche n di natura simile (come i 5 filtri, o alcune trasformazioni, o alcuni processori di dati, ...) Mi piace dividerli in una storia separata per ogni funzione in modo che se una delle funzionalità incontra problemi imprevisti, posso spostare le altre storie fino al completamento. È più per ragioni amministrative che per tecniche, suppongo, e il sovraccarico amministrativo è un po 'più grande quando è fatto in questo modo, ma rende più facile tracciare il lavoro svolto o meno, e il progresso di ogni storia .
Quando ero indottrinato a UML (che è una metodologia diversa ma mi piace ancora questa lezione) la premessa di un caso d'uso era: "Qualcuno arriva al sistema, fa qualcosa di valore aziendale e poi se ne va". Ciò ha fornito un bel confine tra i casi d'uso, perché ha diviso il lavoro in un numero di flussi di processo più o meno completi.
Inizia da A, fai questo e questo e questo, finisci a B. Se non riesci ad arrivare a B, lancia un'eccezione. Passare da B a C, o da A a X, sono flussi diversi.
Mi piacciono gli stessi confini con storie agili, per lo stesso motivo. Quindi, dal tuo esempio precedente, un utente potrebbe venire al sistema, richiamare il filtro 3 e poi andare via. Potrebbero non invocare mai il filtro 2, che suggerisce 2 storie diverse.
Leggi altre domande sui tag agile scrum user-story