Con quale frequenza un team Scrum deve rispettare il proprio impegno Sprint? [chiuso]

10

L'impegno è una promessa e ci è stato insegnato che è necessario mantenere le promesse. Ma è realistico mantenere l'impegno per ogni Sprint? A volte le persone si ammalano, a volte l'approccio tecnico è dimostrato errato e devi ripensare a tutto, a volte durante ulteriori discussioni con il proprietario del prodotto o gli utenti capisci che la funzione dovrebbe essere molto diversa da ciò che inizialmente si pensava.

So che la Guida Scrum ufficiale ora usa la parola "previsione" piuttosto che l'impegno, probabilmente per risolvere questi problemi.

Quindi la mia domanda è: quanto spesso i team delle tue organizzazioni mantengono il loro impegno e se ti piace questo approccio o se vuoi cambiarlo.

Grazie.

    
posta Eugene 14.03.2014 - 09:26
fonte

5 risposte

21

Non è tanto una questione di quanto spesso una squadra dovrebbe "mantenere le sue promesse".
È più una questione di indagare sul perché un team avrebbe un problema a rispettare i propri impegni.

Se si tratta di un intervento divino, non importa. Ma se trovi che hai spesso bisogno di tornare al tavolo da disegno, perché il tuo approccio tecnico è completamente sbagliato, o che l'OP continua a cambiare idea, o che le storie non sono abbastanza chiare all'inizio di uno sprint, allora tu bisogno di indagare perché.

Il mancato rispetto di uno sprint è un sintomo; devi essere interessato alla causa principale.

    
risposta data 14.03.2014 - 10:36
fonte
13

Se tutto va bene, sarà normale che i team rispettino gli impegni di mischia. Dovrebbero essere abbastanza freddi per far fronte a problemi su piccola scala, ragionevoli e probabili, come una malattia di un giorno, emergenze di assistenza all'infanzia, ecc. Senza che si verifichi immediatamente e automaticamente un fallimento nel consegnare il proprio impegno di sprint. Se non è possibile, a mio avviso, gli sprint sono finiti e si stanno facendo troppo caldo per il loro lungo periodo come squadra.

Se gli sprint non riescono a consegnare in modo coerente, la mischia ha mantenuto la sua promessa, per rendere visibili i "problemi". I problemi possono includere non avere compiti correttamente definiti, esperienza insufficiente nel team o una cultura manageriale di cercare continuamente di consegnare oltre - e quindi costantemente in ritardo.

In entrambi i casi, la soluzione è identificare la causa principale e correggerla, piuttosto che frustare più duramente gli sviluppatori.

I team sempre "vicini" al rispetto dei loro impegni stanno fallendo in modo più serio. Puoi star certo che non stanno eseguendo abbastanza test.

    
risposta data 14.03.2014 - 12:47
fonte
4

Personalmente credo che se nessuno nell'organizzazione si preoccupa di soddisfare il tuo impegno, non stai parlando di un impegno. Hai bisogno di due partner per fare un accordo e per formare un impegno.

Un impegno per lo sprint è qualcosa che dovresti essere in grado di mantenere, tenendo conto di tutte le "variazioni normali". Puoi leggere il mio post sul blog sulle basi della pianificazione agile se vuoi sapere di più su cosa intendo con variazione di base. E come ha affermato Stefan , non rispettare il tuo impegno è un sintomo, non la malattia.

Dopo ogni sprint hai un momento per esaminare la velocità effettiva di quello sprint e adattare la tua "velocità media" a quella (come spiegato in il post sopra menzionato ). Se la tua velocità continua a scendere, sprint dopo lo sprint, inizi a vedere i pattern che possono aiutarti a rilevare l'effettiva causa alla radice di questo. Questo potrebbe essere troppo lavoro non pianificato (ad esempio piccoli compiti urgenti in arrivo, bug nel codice su cui si sta lavorando, modifiche ai criteri di accettazione durante lo sprint, ...). Tutti questi dati devono essere rintracciati, molto probabilmente dallo scrum master per aiutarla a capire quali modelli ci sono. Ciò aiuterà la squadra a proporre azioni durante la retrospettiva.

    
risposta data 14.03.2014 - 15:47
fonte
2

La mia prospettiva è che le squadre non stiano prendendo un impegno. Probabilmente, non stanno neanche facendo previsioni. La previsione è fatta prima che lo sprint sia pianificato - la previsione è che in media incontreranno la loro velocità. Ciò significa che a volte faranno alcuni più punti della loro velocità, a volte faranno un po 'meno.

Se stai facendo meno della tua velocità su base regolare, la tua velocità diminuisce per riflettere questo. La previsione scende così pure. Se continui a tirare fuori più storie di quante la tua velocità storica dice che puoi fare sprint dopo lo sprint, non è un fallimento in esecuzione, è un fallimento nella pianificazione. Conosci la tua velocità, quindi non dovresti aggiungere più punti di quanti la storia affermi di poter realizzare.

Per rispondere alla tua domanda specifica, delle tre organizzazioni in cui ho usato scrum, solo una traccia le metriche "miss the commit" nel tempo. Per quella società, i team tipicamente raggiungono le loro previsioni circa l'85% delle volte.

    
risposta data 14.03.2014 - 18:42
fonte
2

Se non rispetti il tuo impegno, dovresti ridurre la velocità. Se lo incontri sempre, dovresti aumentare fino a quando non ci riesci a volte.

Il problema è quanto male fallisci? Dovrebbe essere sempre vicino. O lo fai con un po 'di gioco o fallisci un po'. Questo è un obiettivo salutare per qualsiasi disciplina, tempi di esecuzione, sollevamento pesi, ecc. Idealmente la quantità media di lavoro svolto in uno sprint dovrebbe essere una distribuzione normale attorno alla tua velocità.

Ciò che è più importante è la tendenza a lungo termine nella tua velocità. Se ogni settimana aggiungi 15 punti storia alla tua velocità, ma ne compri solo 10 in più rispetto alla settimana precedente, è davvero una brutta cosa? In alcuni posti considerano questo "traguardo".

    
risposta data 14.03.2014 - 16:29
fonte

Leggi altre domande sui tag