Quando è completato uno Sprint?
Capita abbastanza spesso che un team alla fine di uno Sprint agile o di un'iterazione abbia ancora del lavoro incompiuto. Idealmente, un team completerebbe sempre ogni item nello Sprint Backlog durante lo Sprint. Per vari motivi, tuttavia, questo non è sempre il caso. Ciò ci porta ad alcune domande che affronterò di seguito:
Cosa dovrebbe succedere al rispettivo Product Backlog Item?
Dovrebbe essere suddiviso o portato nel prossimo Sprint? Il team dovrebbe conteggiare i punti per le parti completate della Story nella Velocity?
L'item è ancora rilevante?
Quando un Product Backlog Item non viene completato alla fine di uno Sprint, dovrebbe essere riportato nel Product Backlog. Il lavoro non viene mai trasferito automaticamente da uno Sprint al successivo.
Forse sono un po' pignolo su questo argomento, ma il punto è che ogni Sprint dovrebbe iniziare con il Product Owner che prende una decisione consapevole su cosa il team dovrebbe lavorare. Naturalmente, è molto probabile che il Product Owner voglia che il team completi nel nuovo Sprint il lavoro incompiuto dello Sprint precedente. Tuttavia, questa dovrebbe sempre essere una decisione consapevole del Product Owner.
(Solo come nota: non sto dicendo che dovresti crearti lavoro extra se usi uno strumento con cui questo sarebbe troppo complicato. Dico solo che il lavoro non viene trasferito automaticamente al prossimo Sprint. Il Product Owner dovrebbe sempre decidere se il lavoro è ancora rilevante.)
Suddividere o portare al prossimo Sprint?
Quando un Product Backlog non può essere completato del tutto, i membri del team spesso si chiedono se lasciare il Product Backlog Item così com'è (anche se una parte della funzionalità è già pronta) o se riscriverlo in modo da descrivere solo la parte mancante.
Esempio: Prendiamo come esempio un team che lavora su una tipica funzione di anteprima di stampa per un'applicazione desktop. Se il team ha completato tutto tranne la funzione per sfogliare le pagine all'indietro, i membri del team possono portare la User Story originale nel prossimo Sprint oppure scrivere una Story più piccola: "Come utente, voglio poter sfogliare all'indietro quando viene visualizzata l'anteprima di stampa."
Se la Story verrà completata nello Sprint successivo, suggerirei di lasciarla così com'è e di non riscriverla. Tutti conoscono la Story così com'è stata scritta finora. Quindi, se il Product Owner la ritiene ancora importante, passa invariata al prossimo Sprint.
Se invece il lavoro rimanente viene rimandato a uno Sprint successivo, dovrebbe essere scritta una nuova Story che descrive solo la parte incompleta della funzionalità.
Nota: Se il lavoro viene completato nel prossimo Sprint, la Story non viene riscritta.
Il team ottiene punti per la Velocity?
Tendo ad adottare una posizione piuttosto conservativa riguardo alla Velocity. Ciò significa che un team dovrebbe ricevere punti solo per il lavoro che è effettivamente completato al 100%. Questo significa:
Se un Product Backlog Item incompiuto viene portato nel prossimo Sprint e poi completato, il team non dovrebbe ricevere punti per esso nello Sprint originale. Invece, il team riceve tutti i punti per la Story nello Sprint in cui il lavoro viene effettivamente completato. Poiché sono comunque favorevole a lavorare con una Velocity media, la cosa si bilancia e non c'è rischio che la Velocity venga sopravvalutata.
Diverso è il caso in cui il team suddivide la Story e rimette il lavoro rimanente nel Product Backlog per lavorarci in seguito. In questo caso, i punti per il lavoro svolto vengono accreditati al team. I membri del team devono quindi stimare nel modo migliore possibile quanti punti vale il lavoro completato. Anche se la Story complessiva non è ancora finita, è possibile che il team riceva tutti i punti originali per la Story, perché la Story potrebbe essere stata più grande del previsto. Questo non dovrebbe accadere costantemente, ma ogni tanto va bene.
Conclusione: cercare sempre la causa
Se alla fine dello Sprint c'è ancora del lavoro incompiuto, il team dovrebbe sempre prendersi del tempo nella retrospettiva per scoprire se la causa era evitabile. A volte è semplicemente sfortuna o cattivo tempismo; ad esempio quando un membro del team si ammala o emerge un problema che non era prevedibile all'inizio dello Sprint. È comunque sempre consigliabile riflettere su quale sia stata la causa e come si possa prevenirla in futuro.
Questo testo proviene dal blog di Mike Cohn ed è stato tradotto in italiano.
User Story, Epic, Theme
Spieghiamo la differenza tra questi item.
=>User Story, Epic, Theme
Sviluppare un prodotto
Dall'idea al completamento con il Product Vision Board.
=>Product Vision Board
Cosa sono gli Story Point?
Scopri dove puoi migliorare le stime del tuo team.
=>Cosa sono gli Story Point?
