La definizione di Scrum dice che dovrebbe essere fatta una storia alla volta. Ma se la squadra è abbastanza grande (diciamo 6+), ci sono alcune volte in cui prendere solo una storia è discutibile, ed è ancora di più se ci sono molte piccole storie.
Quindi, a volte nel team con cui sto lavorando, potremmo affrontare due storie il più delle volte. È una brutta cosa?
No, non è male. Durante la pianificazione, il team di riunione si impegna a scrivere storie degli utenti che verranno consegnate nello sprint imminente. Lo sprint è una zona sicura per il team e il team decide come consegnare le storie degli utenti. Se non è possibile per tutti i membri del team lavorare su compiti tratti dalla storia utente più importante (per priorità aziendale) è ovvio che dovrebbero lavorare anche su un'altra storia utente per trarre il massimo vantaggio dalla loro capacità di tempo.
Btw. dove hai trovato che la squadra non dovrebbe lavorare su più di una storia utente alla volta? Puoi guardare il problema come Scrum master. Se il team lavora solo su una storia utente alla volta e qualcuno non ha altri compiti da svolgere, è bloccato = impedimento. Come lo risolvi come Scrum master? Rimuoverai l'impedimento rimuovendo la regola in modo che lo sviluppatore non si blocchi più e possa continuare su un altro utente.
Penso che questa regola sia stata probabilmente menzionata in quanto il membro del team non dovrebbe lavorare su più di una storia utente alla volta (eccetto gli scenari in cui il lavoro sulla storia utente corrente è bloccato da un altro impedimento). Questo ha senso perché il cambio di contesto nel cervello umano è costoso e dirompente. Inoltre rende il processo Scrum molto più controllato perché hai una serie limitata di user story in corso. Ciò corrisponde ai limiti del Work in progress in Kanban.
Non esiste tale restrizione. Se le storie sono indipendenti l'una dall'altra, o se la dipendenza tra loro è minima, puoi certamente farle in parallelo. Ovviamente un membro lavorerà solo su una storia alla volta e idealmente dovrebbe passare a quella successiva solo dopo aver completato una storia. Ma se finisci l'80% di una storia e il restante 20% è in attesa di qualcun altro, puoi proseguire definitivamente, a patto che tu possa terminare la codifica e il test all'interno dello stesso sprint.
Non esiste alcuna regola in Scrum che specifichi quanto lavoro il team è autorizzato a svolgere nello stesso momento. Il tuo compito è capire che cosa si adatta meglio alla tua squadra.
Scrum limita il work in progress (WIP) su l'intero sprint . Ciò significa che ti impegni a consegnare, ad esempio, 20 articoli di lavoro in questo sprint. Non importa quanti di loro stiano lavorando contemporaneamente fino a quando rispetti il tuo impegno.
Confronta questo con Kanban che limita anche WIP, ma per flusso di lavoro stato . Ad esempio, il limite WIP per "test" è 3, il che significa che non sono consentiti più di 3 articoli nella fase di test contemporaneamente.