L'oggetto Sprint richiede più tempo del previsto. Cosa dovremmo fare?

Con "item", suppongo tu intenda "task".

La pianificazione dell'ottimismo nel software è vecchia quanto il software stesso. La cosa buona della mischia è che ci si trova di fronte a esso presto e ne si crea visibilità: questo è il motivo per cui la velocità del team si basa su dati passati e non su stime future.

Per completare una storia, devi anche completare le attività che risultano molto più difficili del previsto. Nessuna scusa per rimandarli. (Questo è il motivo per cui la definizione di fatto è così importante). Se ciò significa che la squadra sta fallendo una storia, quindi troppo male, avrai qualcosa di cui parlare nella tua prossima retrospettiva. La velocità diminuirà (diventerà più realistica) e il team imparerà a fare stime migliori o lascerà più margini di sicurezza per attività impreviste. Il proprietario del prodotto otterrà una visione più realistica sulla sua pianificazione del rilascio.

What should we do if a item in scrum takes longer then expected?

Supponendo che per articolo si intenda una storia, alla fine dello sprint di solito lo si rimette nel backlog del prodotto (e probabilmente lo si pianifica per la successiva iterazione). Il team totalizza zero punti per l'iterazione corrente.

Un'altra alternativa, se la trama è abbastanza grande, è tagliarla verticalmente . Ad esempio, la storia "ricerca catalogo prodotti" può essere suddivisa in "ricerca per categoria" e "ricerca testo completo", ma non in "modulo di ricerca" e "risultati di ricerca".

How can we avoid such situation in future?

Non c'è una risposta diretta facile a questo. In mischia fai sprint di retrospettive ogni iterazione, in cui di solito discuti questo tipo di cose con il team. Ci sono molte possibilità diverse:

• Il team o alcuni membri del team ha una brutta settimana
• Il team esegue la pipeline degli elementi di lavoro orizzontalmente (ad es. backend- > frontend- > QA)
• Le storie sono troppo grandi per errore
• La squadra "tavole d'oro" le storie aggiungendo lavoro extra che non è strettamente necessario per il completamento della storia.
• Le storie sono di natura molto grande, hai bisogno di sprint più lunghi (improbabile)
• Il team stima le storie in modo impreciso (incoerentemente)
• Il progetto ha un sacco di debito tecnologico / codice di base marcia e la tua velocità è troppo bassa
• Non stai misurando e stimando la tua capacità sprint correttamente (o affatto).

ecc. ecc.

Dici che non lo finirai, ma non è male, sono solo dati.

"Incontra la timeline dello sprint" non è un obiettivo. Il tuo obiettivo è completare le storie degli utenti. La cronologia è solo uno strumento per aiutarti a misurare e imparare quanto lavoro puoi fare in uno sprint.

Se sei sicuro di non riuscire a finire il lavoro nello sprint, una soluzione è spostarlo in fondo alla lista delle priorità e lavorare prima sulle altre storie nello sprint. Quindi, con il tempo rimanente, puoi iniziare a lavorarci su. Riesegui la stima del lavoro per il prossimo sprint e finisci quindi.

Assicurati nella tua retrospettiva di discutere su cosa è andato storto in modo da poter migliorare le tue stime in futuro.

Se un'attività richiede più tempo del previsto, questa dovrebbe essere presentata in retrospettiva e discussa. C'è stato un pezzo mancato nelle prime analisi? Era qualcosa che non era già stato fatto spesso dal team? Ci sono molte possibili ragioni per cui qualcosa potrebbe richiedere più tempo di quanto inizialmente stimato.

Il team dovrebbe cercare di portare a termine l'attività nel miglior modo possibile e poi in retrospettiva discutere le strategie su questo in futuro. Se il team è abbastanza nuovo nell'usare Scrum, potrebbe far parte della velocità iniziale del team. Alcune squadre possono pensare di poter fare 20 punti e alcune squadre possono fare 60 punti, il punto è come in modo costante può essere fatto lo stesso numero di punti ogni sprint.

Questo succederà in futuro poiché ogni volta che il team ha nuovi compiti che non ha mai fatto prima ci sarà un po 'di tempo per elaborare i nodi delle stime. Questo fa parte del processo di apprendimento che non dovrebbe essere così sorprendente.

Ciò che facciamo di solito nella nostra azienda quando un'attività inizia a richiedere più tempo del previsto è dividerlo in attività più piccole.

In questo modo non attribuiamo tutte le colpe allo sviluppatore per essere troppo lenti, ma riconosciamo anche che l'attività è stata progettata in modo errato.

Un'altra cosa potrebbe essere quella di assegnare l'incarico a un altro membro del tuo team di sviluppo per evitare che il tuo sviluppatore tardivo si scavi in una buca. E se l'attività è davvero critica, alcuni XP potrebbero essere la soluzione.