E 'appropriato avere uno sprint "clean up" per iniziare al fresco senza punti di riporto?

Sembra che tu non stia tenendo conto della tua velocità.

Se inizi con uno sprint di 100 unità di pianificazione, ma completi solo 90, la tua velocità è 90.

Quando porti più di 10 unità di pianificazione, devi accettare solo 80 nuove unità di pianificazione. Questo ti dà uno sprint di 90 unità di pianificazione che corrisponde alla tua velocità attuale. Se scopri di aver terminato prima della fine prevista dello sprint, aggiungi altre unità di pianificazione allo sprint successivo.

Se trasporti più di 10 unità di pianificazione e assumi altre 90 unità di pianificazione, lo sprint è composto da 100 unità di pianificazione. Sulla base della velocità di 90, ci si può aspettare di avere 10 unità di lavoro di pianificazione rimaste alla fine della primavera.

Nel tempo avrai un'idea migliore della tua velocità e pianifichi meglio. Aspettatevi la variazione della velocità tra gli sprint. Le unità di pianificazione sono stime, quantità non note. Con l'esperienza le stime dovrebbero migliorare e avere una varianza inferiore.

Uno sprint clean-up non è completamente una cattiva idea, specialmente se le cose sono andate così male, che non puoi davvero intraprendere nessun nuovo lavoro. Tuttavia, in vero stile Agile, non dovresti aver bisogno di uno sprint di pulizia in primo luogo.

Devi affrontare l'elefante nella stanza qui - se vedi gli stessi problemi spuntare ogni sprint, allora tu (e più del team) devi fare qualcosa al riguardo. Ciò demoralizzerà ulteriormente la squadra se non realizzeranno mai i loro impegni. Ricorda lo scopo dei punti storia e degli obiettivi di sprint, dà al team qualcosa di realistico da mirare.

1. Esaminare e adattare utilizzando il feedback in retrospettive - Stai tenendo retrospettive in cui il team ha identificato uno di questi problemi?
2. Misura il tempo tra gli stati - Strumenti come JIRA aiutano a mostrare il tempo ciclo tra gli stati delle tue storie utente. Ad esempio, se una storia trascorre 5 giorni in corso, ma per 4 di quei giorni la storia era in QA, hai chiaramente un problema con il controllo qualità

La maggior parte di questa risposta è teorica. Ho incluso quello che potrebbe essere il punto cruciale del problema alla fine. Ma probabilmente dovresti leggere tutta la risposta.

In base alla Guida di Scrum :

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”

Quindi la prima domanda: l'incremento è sempre sbloccabile?

In caso negativo, perché no?

Se lo è, qual è questo concetto di "ripulire"?

Indipendentemente dal fatto che le parti interessate e il proprietario del prodotto siano d'accordo sul fatto che i cambiamenti nell'incremento siano ciò che volevano, sono presenti. È possibile che il Product Owner non si desideri rilasciare fino a quando non viene fornita una futura Incrementation, ma finché è releas able , il Product Owner deve accettare l'incremento. In caso contrario, il proprietario del prodotto e il team di sviluppo dovrebbero capire se qualcosa da questo Incremento è recuperabile, e lo Scrum Team (Product Owner + Scrum Master + Development Team) dovrebbe lavorare per capire come il Team di sviluppo non è riuscito a fornire un Incremento rilasciabile. Non avere un nuovo Incremento è lontano dall'ideale, ma ogni sforzo sprecato è limitato a uno Sprint al massimo, e sono state identificate nuove intuizioni e opportunità di miglioramento.

Quindi il problema è in realtà se il team di sviluppo ha un lavoro annullato nell'incremento (ad esempio funzionalità appena interrotte o funzionalità non testate / non documentate che vengono unite ma che non soddisfano la definizione di " Fatto "), o se hanno il lavoro incompiuto , ovvero che hanno fornito alcune delle funzionalità richieste e il prodotto funziona in modo accettabile, ma non all'altezza delle parti interessate sperato.

Se annullato , l'Increment non è rilasciabile - considera come spiegato sopra. Se non finito , valuta quali modifiche future sono richieste / desiderate e chiedi al Product Owner di aggiungerle nella posizione appropriata nel Product Backlog, quindi consenti al team di sviluppo di stimare i nuovi articoli.

Proprio perché ci sono state delle precedenti aspettative di consegna, il team di sviluppo deve iniziare e terminare lo Sprint con un Incremento rilasciabile. Prendendo questo incremento, è probabile che lo sviluppo sia in grado di eseguire una certa quantità di lavoro. Sii empirico. Utilizza le conoscenze acquisite in precedenza per capire cosa si può fare e il team di sviluppo dovrebbe essere in grado di prevedere cosa può offrire nel prossimo Sprint (nota: la Guida Scrum si riferisce ora alla previsione dei Team di sviluppo, piuttosto che commettere - è solo essere realistici). Uno Sprint che offre meno delle previsioni non è un motivo per aspettarsi che il prossimo Sprint fornirà di più. Se qualcosa ha limitato la capacità del team di consegnare una certa quantità all'ultimo Sprint, a meno che il problema non sia stato identificato e risolto, non c'è motivo di aspettarsi che il team fornisca di più la prossima volta.

Qualunque cosa sia accaduta, usa Sprint Review in modo da consentire a Scrum Team e Stakeholder di minimizzare il rischio che ciò accada di nuovo. Usa Sprint Retrospective per stabilire nuovi modi di lavorare e potenzialmente una modifica alla definizione di "Fatto" per ridurre al minimo il rischio che si ripeta.

Dalla tua domanda, penso che il vero problema (che probabilmente identificherai anche usando Scrum rigorosamente) è che il tuo team di sviluppo non è responsabile per il controllo qualità. Non tutti i membri del team di sviluppo devono avere le stesse competenze (non è necessario essere uno "sviluppatore" in quanto tale). Il team deve essere in grado di fare tutto ciò che è necessario per produrre un Incremento "Fatto", rilasciabile. Il passaggio logico potrebbe essere l'aggiornamento della definizione di "Fatto" per includere il controllo qualità, inclusi gli ingegneri del controllo qualità all'interno del team di sviluppo e potenzialmente la modifica di strumenti / sistemi per supportare questo modo di lavorare.

No.

Questo è un problema che puoi risolvere con il controllo delle versioni piuttosto che con la gestione del progetto.

Trasportare la storia (s) nel prossimo sprint e accettare nuove storie come normale. Ma unisci le storie di "ripulitura" nella versione precedente e le nuove storie nella nuova versione, nello stesso modo in cui faresti una correzione.

In questo modo è possibile "completare" una versione per il rilascio utilizzando la capacità di riserva sulle nuove funzionalità. Avere contemporaneamente due versioni in movimento farà presagire il test, quindi fai attenzione a non lasciarlo sfuggire di mano

Riconoscere quando è il momento di ripulire e non assumerne altri è una buona cosa. Chiamare che uno sprint è una cosa strana.

Normalmente fa parte di uno sprint. Ho lavorato in due sprint settimanali, in lunghi sprint mensili e in una settimana di sprint (preferisco di gran lunga gli sprint settimanali). Indipendentemente dalle dimensioni, sono sempre molto prudente con il lavoro che intraprendo. In una settimana di sprint chiedo quello che penso come un giorno degno di lavoro. Devo perché sono fortunato se riesco a passare una giornata di lavoro su una cosa qualsiasi in una settimana.

Ho sempre lo scopo di avere qualcun altro a guardare le mie cose prima che lo sprint finisca. Cerco di dare loro un giorno (un giorno reale) almeno. Cerco di lasciare un giorno per me per sistemare tutto ciò che trovano e ripulire il giorno dopo. Se soffio, arrivo nel weekend. Quindi perché non sto spendendo ogni fine settimana al lavoro?

Ecco il vero trucco. Nel momento in cui sospetti persino che ci sia una possibilità che non farai la scadenza, rivedi il tuo preventivo. Trovi una piccola quantità di lavoro che può essere raggiunto, testato, ripulito e spedito prima della fine dello sprint. Lasciate tutto ciò che non riuscirai a finire nel backlog il prima possibile. Forse lo finirai più tardi. Forse qualcun altro lo fa. Non ti reggi al lavoro, non finirai in tempo.

Se questo significa che hai finito bene il martedì. Trascorri mercoledì ricerche, giovedì allenamento, venerdì pianificando cosa farai il prossimo sprint.

Non dovrebbe essere ripulito che viene spostato al prossimo sprint. È la seconda parte del problema che stai cercando di risolvere. Uno sprint finisce davvero quando puoi dimostrare di aver fatto qualcosa di utile.

Stai essenzialmente parlando di un vincolo. La natura stessa di un vincolo è che influisce negativamente sul rendimento totale. Pensa a un bancone del pranzo con 5 posti. C'è una fila di persone che aspettano intorno all'isolato per ogni pranzo e le prime 5 si siedono e ordinano. Tuttavia, hai un solo cuoco, che per ragioni di discussione, diciamo, può cucinare solo il pasto di una persona alla volta. Il cuoco è il tuo limite. L'aggiunta di più posti al banco non farà altro che peggiorare il tuo problema, aggiungendo agli ordini che il cuoco non è in grado di soddisfare.

Potrebbe sembrare un argomento per il tuo "clean-up sprint", ma il problema è che non è una soluzione permanente. Certo, il carico sul QA si riduce per un po ', ma mentre il resto della tua squadra sale le rampe, improvvisamente sono di nuovo indietro e mancano di nuovo gli obiettivi. L'unica soluzione reale è di rallentare l'intera pipeline in modo tale che il vincolo non sia più un vincolo (la roba si muove attraverso l'intera pipeline ad un passo costante e coerente, se lento,) o rimuovere il vincolo, aggiungendo migliori strumenti di prova, più membri del team QA, ecc.