Cosa devo fare se il membro Scrum parte a metà?

Devi de-scopeare le storie meno importanti e spostarle al prossimo sprint. La tua capacità è cambiata e lo sprint dovrebbe rispecchiarlo.

Se il cliente aggiunge una nuova grande storia ad alta priorità, cosa fai? Accettalo e aggiungilo allo sprint? Re-piano? Cambia il grafico di burn-down? Mordere il proiettile? No. Disattivi altre storie perché non hai capacità.

Questo non è diverso: le circostanze sono cambiate e il tuo team non può più impegnarsi nello scope iniziale.

1. Nessun. Non chiedi alle persone di lavorare ore extra. Vuoi più partire?
2. Che cos'è un grafico di burn-down? È il grafico di quali punti sono completati rispetto al grafico di quali punti è necessario completare prima della scadenza. Allora perché cambiarlo? Tieni traccia dei grafici e vedrai l'effetto che ha la perdita di uno sviluppatore e può tenere informato il cliente.
3. Il cliente può utilizzare tali informazioni per declinare o estendere la scadenza. Quello che non possono essere autorizzati a fare è dire che vogliono più risorse. Le risorse arrivano quando le trovi e vanno quando ne hanno voglia e forzando la persona sbagliata velocemente non risolveranno il tuo problema. Ciò è particolarmente vero con l'avvicinarsi della scadenza.
4. Se hai intenzione di assumere qualcuno, aspettati che ci voglia del tempo, quindi il costo sarà di più di un'ora di sviluppo, e il guadagno non sarà immediato.
5. Fai notare al business che se non vogliono che ciò accada in futuro, hanno bisogno di assumere troppe risorse all'inizio del progetto e di anticipare il requisito previsto fino a una scadenza prossima (quando, perché sono in vantaggio, possono perdere metà della squadra e non sostituirli in un momento in cui gli sviluppatori restanti non hanno bisogno di passare il tempo per allenarsi).

Disclaimer: tutto questo viene fornito con l'avvertenza, "in un mondo perfetto". Ora avvicinati il più possibile e starai bene.

Come membro del team o scrum master non fare nulla se non informare il proprietario del prodotto sulla situazione. Il tuo team si è già impegnato in alcune quantità di storie utente basate su alcune capacità previste. È successo qualcosa di brutto e uno dei membri del tuo team non può continuare a sprint a causa delle condizioni di salute. Ciò può accadere e nessuno può biasimarlo o te per quello.

Spetta al proprietario del prodotto decidere cosa fare dopo. È ovvio che molto probabilmente non consegnerai ciò che hai commesso. Il proprietario del prodotto può continuare lo sprint così com'è, in modo da completare il maggior numero possibile di user story senza membri del team e straordinari irragionevoli o può decidere di interrompere lo sprint e avviarne uno nuovo, ma sarebbe piuttosto drastico.

Il descoping è pericoloso. Sprint dovrebbe essere una zona sicura per la squadra. Fa parte di principi agili per potenziare le persone. Il team ha il potere di prendere un impegno. Una volta che si consente di cambiare l'impegno durante lo sprint, può presto diventare una pratica comune e l'intero punto di impegno e zona sicura scomparirà. Otterrai il caos con il target sprint che cambia continuamente.

Comprendi che la mischia ha velocità per aiutarti a gestirla.

La mia comprensione è che la tua velocità si adatta alla nuova squadra nel tempo. Alcuni luoghi consentono anche di stimare una diminuzione della velocità, per aiutare a gestire meglio quando i membri del team se ne vanno, o anche solo in vacanza.

Analizza l'impatto sullo sprint complessivo. Identificare soluzioni alternative / aggirare. Discutere con il proprietario del prodotto per spostare meno priorità / storie utente importanti per il prossimo sprint. Aggiungi risorse aggiuntive per questo sprint o per lo sprint futuro.