In uno scrum standup, la discussione su ciò che è stato fatto ieri dovrebbe essere limitata ai compiti alla lavagna o a tutto il lavoro svolto?

So che le regole Scrum nelle standup quotidiane dicono che il team dovrebbe solo parlare di quello che hanno fatto ieri, di quello che stanno facendo oggi e di qualsiasi cosa li blocchi. Nient'altro. Ma il problema è che a volte gli sviluppatori trascorrono la loro giornata a lavorare in modo irrilevante per i loro compiti, e poi ne parlano in piedi. È quello che hanno fatto ieri!

Nella mia esperienza, ho scoperto che è più efficace parlare dei compiti alla lavagna, mantenere lo standup concentrato e mantenere l'attenzione di tutti sui loro compiti, rivedere le loro stime e tenere traccia dei loro record quotidianamente.

È valido limitare la discussione ai compiti alla lavagna?

agile scrum meetings

— Shadin
fonte

Che gli sviluppatori trascorrano intere giornate a non lavorare sui loro compiti potrebbe essere un problema che sarebbe invisibile se non menzionato?

— RemcoGerlich,

Tutti parlano per 30 secondi per dire cosa hanno fatto prima. Quanto più focalizzato lo vuoi? Tu non rivedere le stime. Tieni traccia delle attività quando le passi al ragazzo successivo (revisore o tester).

— gnasher729,

Risposte:

In base al contenuto della Scrum Guide sugli standup quotidiani, le tre domande per la discussione sono:

Che cosa ho fatto ieri che ha aiutato il team di sviluppo a raggiungere l'obiettivo Sprint?

Cosa farò oggi per aiutare il team di sviluppo a raggiungere l'obiettivo Sprint?

Vedo qualche impedimento che impedisce a me o al team di sviluppo di raggiungere l'obiettivo Sprint?

Tutte le domande si concentrano sull'obiettivo di Sprint, non sui compiti che si trovano sulla lavagna. Ancora una volta, secondo la Scrum Guide, lo Sprint Goal viene creato in Sprint Planning e definisce "un obiettivo che verrà raggiunto all'interno dello Sprint attraverso l'implementazione del Product Backlog e fornisce una guida al team di sviluppo sul perché sta costruendo il Incremento".

Tutto ciò che fa il tuo team di sviluppo dovrebbe idealmente aiutare il team a progredire verso l'obiettivo Sprint. Queste potrebbero essere attività non pianificate che non sono sul tabellone che dovevano essere fatte, oppure potrebbero essere cose a un livello inferiore che potrebbero essere state considerate e stimate, ma a un livello inferiore rispetto a un elemento sul tabellone.

Direi che lascia che la tua squadra parli di tutto ciò che hanno fatto ieri. Se stanno parlando di cose che non aiutano la squadra a raggiungere l'obiettivo Sprint, allora qualcuno dovrebbe tirarlo fuori, specialmente se ci fossero altre cose che avrebbero potuto fare che hanno avvicinato la squadra al completamento dell'obiettivo Sprint.

Un'eccezione può essere se un individuo supporta più team Scrum. Durante l'incontro, probabilmente non dovrebbero parlare di tutto quello che hanno fatto ieri, ma di quello che hanno fatto a supporto della squadra che sta attualmente facendo stand-up.

La Sprint Retrospective è un ottimo momento per parlare di questo problema con il team. Ci sono molte domande da considerare:

Il team è sottoelaborato su articoli relativi allo Sprint Goal?
C'è troppo lavoro non pianificato?
Da dove proviene il lavoro non pianificato e chi lo sta autorizzando?
Perché le persone stanno lavorando su cose che non sono alla lavagna?
Dovremmo mostrare più dettagli sul tabellone per legare più facilmente le cose che fai agli oggetti sul tabellone?

— Thomas Owens
fonte

il problema con "Sprint Goal" è troppo vago e volgare. in pratica Sprint Goal == completa le attività sul tabellone. se quello su cui hai lavorato non è lì o dovrebbe essere o non dovresti lavorarci

— Ewan

@Ewan Un cliente chiama e ci dice che il software live si è bloccato e abbiamo un registro e una segnalazione di bug. È importante prenderti il tempo necessario per valutare immediatamente quel rapporto, anche se non è in questo momento. Potrebbe essere portato nel campo di applicazione o potrebbe essere messo nel backlog, ma è qualcosa che ho fatto ieri e potrebbe essere il motivo per cui non avrei potuto aiutare Bob con il suo problema fino a dopo pranzo. Non dovrei svolgere questo compito alla cieca, ma probabilmente nessuno lo metterà sul tavolo se non viene inserito in questo Sprint. Posso pensare anche ad altri esempi.

— Thomas Owens

dovresti aggiungere un biglietto "triage live bug" alla scheda e contrassegnarlo come fatto. Quindi alla fine dello sprint puoi dire con certezza. 'questo sprint abbiamo trascorso X ore a esaminare gli errori degli utenti. Ecco perché siamo in ritardo. dobbiamo addestrare meglio l'helpdesk 'Altrimenti non fai nulla per quello sprint e il PM ha appena sentito scuse dal team' oh ci sono stati un sacco di bug da guardare questa settimana! scrollata di spalle "

— Ewan,

@Ewan Penso che sia incredibilmente inutile. Non voglio passare la giornata a scrivere i biglietti. Un processo deve farmi svolgere il mio lavoro e impiegare 90 minuti per eseguire il triage invece di 95 minuti per eseguire il triage e quindi inserire un biglietto in cui si dice che il triage di un biglietto è sciocco. Soprattutto se devi triage più biglietti. Non hai bisogno dei biglietti per discutere delle cose alla retrospettiva. Se stai usando strumenti elettronici, puoi trovare i biglietti modificati dal team nello Sprint per vedere se c'erano molte cose da triage - nessun sentito dire lì.

— Thomas Owens

il livello di segnalazione se fino al tuo scrummaster / pm / azienda. potresti semplicemente scrivere un biglietto "trigaing bugs" per coprire tutto il tuo lavoro per la giornata. Ma la cosa importante è che la REGISTRA COME PARTE DELLA SPRINT. non dare per scontato che sia stato preso in considerazione da un'altra metrica

— Ewan,

No, dovresti parlare di quello che hai fatto ieri.

Se non è sulla scheda, devi eseguire una delle seguenti operazioni:

mettilo alla lavagna,
smetti di farlo
o cambia squadra.

Il più comune, diciamo per i lavori di emergenza non pianificati, è scrivere una carta e incollarla sul tabellone. Ciò garantisce che alla fine dello sprint sia possibile misurare la velocità e spiegare perché gli obiettivi dello sprint non sono stati raggiunti.

Un membro del team che lavora su cose che non sono nello sprint è a mio avviso uno dei motivi principali per cui le adozioni agili falliscono. Più comunemente si tratta di uno sviluppatore deviato per risolvere problemi in tempo reale su un altro progetto.

Un'altra cosa fastidiosa negli sprint è "PM che parla di incontri per altri progetti". A mio avviso, il PM non fa parte del team di Scrum, ricopre il ruolo di Scrum "Product Owner" e quindi è lì per rispondere alle domande, non per segnalare i progressi.

— Ewan
fonte

C'è qualcosa come il lavoro non pianificato - il lavoro che deve essere fatto per sbloccare qualcuno o fare altre attività che si trovano sulla scacchiera, ma non è sulla lavagna. Spesso, potrebbe essere più veloce farlo e poi metterlo sul tabellone. Sta al team discutere di come gestirlo. Il mio attuale team ha delle regole: tutto ciò che viene distribuito in un ambiente di produzione o di controllo qualità o attività che richiedono 2 ore vanno alla lavagna. A volte ci sono ancora compiti più brevi che devono accadere di cui si parla ma non fanno il consiglio perché non soddisfa i criteri.

— Thomas Owens

@Ewan, puoi per favore ampliarlo? Chi gestisce la correzione di bug live, se non è nello Sprint? Come può il Project Manager essere contemporaneamente Project Manager? (Voglio dire chi è lui o sta destreggiandosi in entrambi i ruoli)

— Dennis,

modificato per chiarezza

— Ewan,

@Dennis: Project Manager non è un ruolo Scrum.

— RemcoGerlich,

@Ewan, grazie. Questo non è essenziale per la risposta, ma sono curioso: il "Primo Ministro parla di incontri per altri progetti", come funziona? I PM entrano in una riunione sul progetto X, ma parlano di Y? Ho difficoltà a visualizzarlo. Come / perché è possibile? Vuoi dire che entrano e iniziano essenzialmente a spettegolare o andare fuori tema o c'è una ragione più profonda per parlare di obiettivi / bisogni specifici di una riunione non immediata? Direi "ehi bello sentirlo, ma non faccio parte del progetto Y ... nessuna conoscenza / esperienza lì, possiamo tornare a X?"

— Dennis,