Confuso sulla modifica del backlog dello sprint durante uno sprint

Ultimamente ho letto molto su Scrum e ho trovato quelle che mi sembrano informazioni contrastanti sull'opportunità o meno di modificare l'arretrato di sprint durante uno sprint. L' articolo di Wikipedia su Scrum dice che non va bene, e anche molti altri articoli lo dicono. Anche il mio professore di sviluppo software ha insegnato la stessa cosa durante una panoramica della mischia.

Tuttavia, ho letto Scrum e XP dalle trincee e che descrive una sezione per gli elementi non pianificati sulla scheda delle attività. Quindi ho cercato la Scrum Guide e mi ha detto che durante lo sprint "Non sono state apportate modifiche che potrebbero influire sull'obiettivo Sprint" e nella discussione dell'obiettivo Sprint "Se il lavoro risulta essere diverso da quello previsto dal team di sviluppo, quindi collaborano con il Product Owner per negoziare l'ambito di Sprint Backlog all'interno dello Sprint. " Continua dicendo nella discussione sullo Sprint Backlog:

Lo Sprint Backlog è un piano con dettagli sufficienti per comprendere i cambiamenti in corso nel Daily Scrum. Il team di sviluppo modifica lo Sprint Backlog durante lo Sprint e lo Sprint Backlog emerge durante lo Sprint. Questa emergenza si verifica quando il team di sviluppo lavora attraverso il piano e apprende di più sul lavoro necessario per raggiungere l'obiettivo Sprint.

Poiché è necessario un nuovo lavoro, il team di sviluppo lo aggiunge allo Sprint Backlog. Man mano che il lavoro viene eseguito o completato, il lavoro rimanente stimato viene aggiornato. Quando gli elementi del piano vengono considerati non necessari, vengono rimossi. Solo il team di sviluppo può modificare il proprio backlog di Sprint durante uno Sprint. Lo Sprint Backlog è un'immagine altamente visibile e in tempo reale del lavoro che il team di sviluppo ha intenzione di realizzare durante lo Sprint e appartiene esclusivamente al team di sviluppo.

Quindi a questo punto sono del tutto confuso. Pensandoci, ha più senso per me adottare il secondo approccio. I singoli elementi specifici nel backlog non mi sembrano la cosa più importante, ma piuttosto l'obiettivo dello sprint, quindi non ha senso l'obiettivo dello sprint ma essere in grado di cambiare il backlog ha senso. Ad esempio, se sia il proprietario del prodotto che il team pensavano di trovarsi sulla stessa pagina di una storia, ma mentre lo sprint procedeva, capivano che c'era un malinteso, sembra che abbia senso cambiare i compiti che compongono quella storia di conseguenza . O se ci fosse una storia o un'attività che è stata dimenticata, ma è necessaria per raggiungere l'obiettivo dello sprint, penso che sarebbe meglio aggiungere la storia o l'attività all'arretrato durante lo sprint.

Tuttavia, ci sono molte persone che sembrano abbastanza irremovibili che qualsiasi modifica al backlog dello sprint non sia corretta. Sto fraintendendo quella posizione in qualche modo? Quelle persone stanno definendo il backlog dello sprint in qualche modo diverso? La mia comprensione del backlog dello sprint è che consiste sia nelle storie che nei compiti in cui sono suddivise.

Ad ogni modo, apprezzerei molto il contributo su questo problema. Sto cercando di capire sia l'approccio idealistico della mischia per cambiare l'arretrato di sprint durante uno sprint, sia se le persone che usano la mischia con successo per lo sviluppo consentono di cambiare l'arretrato di sprint durante uno sprint.

Innanzitutto non avrei regole rigide a riguardo; l'intero punto di mischia è permetterti di adattarti alla situazione. Quindi dovresti essere in grado di modificare il backlog dello sprint durante lo sprint, se assolutamente necessario (come se avessi dimenticato qualcosa di critico).

Ma dire questa modifica al backlog dello sprint durante lo sprint dovrebbe essere resistito. Il punto centrale dello sprint è che è possibile aggiungere nuovi lavori allo sprint successivo (dopo che è stata correttamente assegnata la priorità) senza influire sulla sequenza temporale complessiva del progetto (più sprint).

Ma se il lavoro è fondamentale per una delle attività in questo sprint hai due opzioni.

1. Aggiungi nuovo elemento allo sprint.
   MA rimuovi un articolo di dimensioni equivalenti dallo sprint.
2. Rilascia l'oggetto che era stato pianificato male da questo sprint (in modo da poterlo pianificare correttamente nello sprint successivo).
   • Aggiunta di un'alternativa (di dimensioni appropriate) dalla parte superiore del portafoglio ordini del prodotto (che dovrebbe essere in ordine di priorità dalla riunione di pianificazione dello sprint).
   • O quando tutti gli elementi dello sprint sono terminati, consente agli sviluppatori di recuperare dal backlog del prodotto.

Quindi sono nel campo che probabilmente non dovresti modificare l'arretrato di sprint. Ma devi tener conto della situazione in cui potrebbero esserci circostanze eccezionali. Nella maggior parte dei casi andrei con le opzioni 2 e lascerei che gli sviluppatori raccolgano il gioco con le attività dal backlog.

Quindi nella prossima riunione di pianificazione il nuovo compito verrà opportunamente analizzato e aggiunto allo sprint (a seconda dei casi).

Ricorda che lo sprint è breve e solo il segno della caduta successiva non la fine del ciclo di sviluppo. Il proprietario del prodotto dovrebbe essere molto disperato per una funzione che non poteva attendere la fine del prossimo sprint.

La confusione è dovuta a un linguaggio ambiguo.

Lo Sprint Backlog ha due livelli di dettaglio. Innanzitutto, è un elenco di articoli (User Story) che il Team si è impegnato a consegnare. In secondo luogo, sono tutti i COMPITI che il team intende fare per fornire ognuna di queste storie.

Quindi, quando le persone parlano dello Sprint Backlog, dovrebbero davvero essere chiari sul loro significato. Quando leggi la Scrum Guide, vedrai che afferma: Lo Sprint Backlog è l'insieme degli articoli Product Backlog selezionati per lo Sprint, oltre a un piano per la consegna dell'incremento del prodotto e la realizzazione dell'obiettivo Sprint.

Quindi è ENTRAMBI l'elenco degli articoli arretrati del prodotto E il piano (attività) per consegnarli.

Ora, a molti team piace aggiungere tutte le attività proposte (piano) all'inizio dello Sprint in modo da poter tracciare un grafico di burndown in base alle ore rimanenti da svolgere. Altre squadre lasciano che i compiti emergano come richiesto. QUESTO è quando va bene aggiungere allo "Sprint Backlog", poiché il team deve farlo per ispezionare e adattare al fine di consegnare gli articoli e raggiungere l'obiettivo Sprint.

In determinate circostanze, un team può essere in anticipo rispetto al programma e (avendo eliminato tutte le altre attività utili che potrebbero migliorare le capacità del team) potrebbe decidere di collaborare con il Product Owner per selezionare un'altra storia (dovrebbe essere già stata data la priorità e le dimensioni) da il Product Backlog ... ma solo se hanno la certezza che sarà completato all'interno di quello Sprint e che si allineerà con lo Sprint Goal.

Quindi, eccolo qui; SÌ ... i team aggiungono le attività al piano Backlog Sprint come richiesto. No, di solito non si aggiungono all'elenco degli elementi del backlog che definiscono l'ambito dello sprint.

Spero che questo chiarisca la situazione.

Dipende dalle tue situazioni. Se durante la pianificazione vengono perse alcune informazioni e in seguito si scopre che è necessario modificare o aggiungere alcuni punti ad alcune storie, allora penso che vada bene. Ma sì, se l'ambito di una funzionalità cambia completamente, si tratta di una situazione estrema e deve essere gestita in modo diverso.

Ma ovviamente, durante la pianificazione, si presume che tutti sappiano e discutano chiaramente di ciascuna delle caratteristiche su cui avrebbero lavorato. Se le discussioni e la pianificazione sono buone, in quasi tutti i casi non sono necessarie modifiche.

Concordo con le risposte, sottolineo che se la storia ha iniziato lo sviluppo non può essere fermata fino al termine.

Scava i talloni all'inizio. Coloro che chiedono il cambiamento dovranno imparare nel modo più duro, altrimenti finirai con la pianificazione di essere inutile se le persone imparano che puoi fare ciò che ti piace comunque.

Cita che la qualità viene dalla concentrazione e gli insetti derivano dall'abbandono di un treno di pensieri. Cita il costo del cambio di contesto. Tracciare il debito e la gestione della scrittura, discutere e interpretare una storia per affrontare il lavoro a metà è costoso. Basta non iniziare su questa strada.

Idea: dare alla direzione 3 crediti di scambio da spendere ogni trimestre come compromesso.