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

10

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

So che la Scrum Guide ufficiale ora usa la parola "previsione" piuttosto che impegno, probabilmente per affrontare 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.

scrum

— Eugene
fonte

meta.programmers.stackexchange.com/questions/6483/…

— moscerino

1

Una domanda che mi sono spesso posto e due buone risposte

— matt freake,

1

Se rispetti sempre il tuo impegno, probabilmente non sei abbastanza aggressivo. Speriamo che la tua precisione migliorerà col passare del tempo, poiché parte dell'obiettivo di Scrum è migliorare le capacità di tutti nel valutare quanto tempo impiegherà un determinato compito nel mondo reale.

— Keshlam,

1

@keshlam non è necessariamente del tutto vero. C'è un'intera scuola di pensiero nel movimento agile che sta attivamente cercando di superare le stime tradizionali, riconoscendone la potenziale natura velenosa.

— Stefan Billiet,

1

Certo, @StefanBilliet ... ma Scrum ha intenzione di ridurre simultaneamente le stime per quanto riguarda il mondo esterno, migliorando nel contempo il senso interno di una squadra di quanto lavoro aggiuntivo saranno probabilmente in grado di svolgere quando.

— Keshlam,

21

Non è tanto una questione di quanto spesso una squadra dovrebbe "mantenere le sue promesse".
Si tratta più di indagare sul motivo per cui una squadra avrebbe un problema a rispettare i propri impegni.

Se è un intervento divino, non importa. Ma se scopri che spesso devi tornare al tavolo da disegno, perché il tuo approccio tecnico è chiaramente 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 sul perché.

Non rispettare un impegno sprint è un sintomo; devi essere interessato alla causa principale.

— Stefan Billiet
fonte

Quindi dovremmo sforzarci di rispettare l'impegno nel 99,99% dei casi? Se questo è il livello di garanzia necessaria che l'impegno sarà rispettato, ci impegneremo solo per metà del lavoro medio che di solito possiamo produrre. Quindi immagino che non sia del 99,99%. Quindi, cos'è? 50-70%? 80-90%?

— Eugene,

@Eugene Perché hai bisogno di un numero e di chi deve essere assicurato? Sto iniziando ad avere l'idea che ci sia qualcuno nella tua organizzazione che ti punirebbe se non raggiungessi i tuoi obiettivi di sprint ...

— Stefan Billiet

Affatto. Infatti nella mia organizzazione a nessuno importa se un impegno è stato rispettato o meno. Sto cercando di cambiarlo, perché attualmente la correzione di bug e la scrittura di test è stata lasciata fuori perché non c'è tempo per loro. Vorrei consigliare ai team di impegnarsi a meno affinché possano adempiere ai loro impegni su base regolare. Ma quanto meno? Se il rispetto dell'impegno è una questione di vita o di morte, allora ti impegnerai sicuramente meno che se fosse solo una previsione su cui nessuno si affida all'esterno.

— Eugene,

2

A quanto pare, hai alcuni problemi più fondamentali. Devi avere una comprensione del team di "fatto" prima di poter misurare le prestazioni sul numero di storie che sono state "fatte"

— Michael Shaw,

13

Se tutto va bene, allora sarà normale che le squadre rispettino i loro impegni di mischia. Dovrebbero funzionare abbastanza bene da far fronte a interruzioni su piccola scala, ragionevoli e probabili come una malattia di giorni, emergenze di assistenza all'infanzia ecc ... senza che ciò causi immediatamente e automaticamente un fallimento nel mantenere il suo impegno di sprint. Se ciò non è possibile, a mio avviso, gli sprint sono finiti per impegnarsi e stanno andando troppo caldi per il loro bene a lungo termine come squadra.

Se gli sprint non riescono costantemente a fornire, allora la mischia ha mantenuto la sua promessa, per rendere visibili i "problemi". I problemi possono includere il fatto di non avere compiti ben definiti, un'esperienza insufficiente nel team o una cultura di gestione che tenti continuamente di consegnare troppo, e quindi costantemente a corto di risorse.

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

Le squadre che sono sempre "vicine" al rispetto dei propri impegni stanno fallendo in modo più serio. Puoi essere sicuro che non stanno eseguendo test sufficienti.

— Michael Shaw
fonte

4

Personalmente credo che se nessuno nell'organizzazione si preoccupa di rispettare 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 di 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 saperne di più su cosa intendo con variazione di base. E come ha affermato Stefan , non rispettare il tuo impegno è un sintomo, non una malattia.

Dopo ogni sprint hai un momento per ispezionare la velocità effettiva di quello sprint e adattare la tua "velocità media" a quella (come spiegato nel post sopra citato ). Se la tua velocità continua a diminuire, sprint dopo sprint, inizi a vedere schemi che possono aiutarti a rilevare la causa principale di ciò. Questo potrebbe essere troppo lavoro non pianificato (ad es. Piccole attività urgenti in arrivo, bug nel codice su cui stai lavorando, modifiche ai criteri di accettazione durante lo sprint, ...). Tutti questi dati devono essere monitorati, molto probabilmente dallo scrum master per aiutarla a capire quali schemi ci sono. Ciò aiuterà la squadra a escogitare azioni durante la retrospettiva.

— talboomerik
fonte

2

La mia prospettiva è che i team non si impegnino. Probabilmente, non stanno nemmeno facendo previsioni. La previsione viene fatta prima della pianificazione dello sprint - la previsione è che in media incontreranno la loro velocità. Ciò significa che a volte faranno alcuni punti in più rispetto alla 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. Anche la previsione diminuisce. Se continui a inserire più storie di quante la tua velocità storica dica che puoi fare uno sprint dopo lo sprint, non è un fallimento nell'esecuzione, è un fallimento nella pianificazione. Conosci la tua velocità, quindi non dovresti portare più punti di quanti la storia non possa dire.

Per rispondere alla tua domanda specifica, delle tre organizzazioni in cui ho usato la mischia, solo una ha monitorato nel tempo le metriche "miss the commit". Per quella società, i team in genere rispettano le loro previsioni circa l'85% delle volte.

— Bryan Oakley
fonte

Essere d'accordo. Ero in una squadra in cui alla fine di ogni pianificazione dello sprint, il manager ha richiesto un impegno per completare tutte le storie per lo sprint. Ho preso l'abitudine di dire "sì" e ho continuato ad essere agile. Ho pensato che probabilmente lo faceva sentire meglio così.

— Rob

1

@RobY: penso che ci sia spazio per l'impegno nelle squadre mature. Nella mia esperienza, i team più agili non sono particolarmente maturi e qualsiasi PO che richiede un impegno non è un buon PO. Facevo parte di una squadra che era piuttosto solida con la sua velocità e ci siamo sentiti abbastanza a nostro agio a prendere impegni reali quando necessario, ma le altre squadre in cui ho fatto parte non sono state così mature.

— Bryan Oakley

Stavo facendo un tuffo nella guancia. Sono d'accordo, di solito c'è un nucleo di storie a cui puoi impegnarti, ma man mano che ti avvicini alla velocità, è un po 'meno certo. Poiché la velocità è una media, a volte per definizione a volte sarai sopra, a volte sotto. A proposito, quello stesso manager ci caricherà ogni volta di 2x o 3 volte la nostra velocità e quindi richiederebbe un impegno ... quindi ...;) (Per lo più stavo reagendo al tuo primo paragrafo, che penso lo affermi davvero bene)

— Rob

2

Se non stai rispettando il tuo impegno, dovresti ridurre la velocità. Se lo incontri sempre, dovresti aumentare fino a quando fallisci a volte.

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

La cosa più importante è la tendenza a lungo termine della tua velocità. Se ogni settimana aggiungi 15 punti storia alla tua velocità ma ne realizzi solo 10 in più rispetto alla settimana precedente, è davvero una brutta cosa? In alcuni luoghi considerano questo "allungare gli obiettivi".

— Slitta
fonte

Non sono davvero d'accordo con questa risposta. La natura umana è cercare di consegnare, e puoi scommettere il tuo dollaro in meno che i team taglieranno i "test" per consegnare, piuttosto che abbandonare la storia. Se sei sempre così vicino alla linea, non testerai abbastanza a fondo e tornerà a mordere.

— Michael Shaw,

@Ptolemy è qui che sono richiesti disciplina, orgoglio professionale e una solida " definizione di fatto ". Questi dovrebbero impedirti di spedire merda. Inoltre, non dovresti contare qualcosa come fatto se hai tagliato gli angoli.

— Slitta

Questo è molto più chiaro da parte dello sviluppatore di quanto non lo sia dalla parte di test della mischia. Non si possono riscontrare difetti noti perché il tester si è concentrato sul test della funzionalità principale e non ha avuto il tempo per "un evento casuale" che ha rivelato il bug.

— Michael Shaw,

2

@Ptolemy: i team non possono tecnicamente "tagliare i test" poiché i test fanno parte della storia. Se lo tagliano, non è diverso dal tagliare parte della codifica. Se ometti parte della funzione in codice, stai completando una storia? Allo stesso modo, se tagli i test, non stai completando la storia.

— Bryan Oakley

Non ho mai usato Scrum ma ho preso impegni e ho giudicato se le cose sono state fatte. Sarebbe bello se la definizione di fatto fosse del tutto oggettiva, cioè non c'è spazio per il gruppo per interpretare la definizione alla luce della necessità di fare per rispettare l'impegno. Essendo il linguaggio naturale quello che è, questo sembra irrealistico. Se sei abbastanza rilassato riguardo all'impegno e abbastanza vicino a una definizione obiettiva, questo non sarebbe un problema. Quando Tolomeo dice "la natura umana è cercare di consegnare", nel mio schema significa che "le persone non sono sufficientemente rilassate riguardo all'impegno".

— Steve Jessop,