Cosa fare quando uno sprint è finito presto?

Cosa fare quando uno sprint è finito presto?

Al momento il nostro team Scrum elabora storie dal backlog, se lo sprint è terminato in anticipo.

Cosa succede con le storie tratte dal backlog? Le storie verranno aggiunte all'attuale Sprint? Se sì, se queste storie non fossero finite in tempo. Lo Sprint è fallito allora?

Porta nello sprint qualcosa dal backlog del progetto (dopo discussioni con il mastro scrum e il proprietario del progetto).

La dimensione dell'articolo che intraprendi dipenderà da quanto tempo hai. Se non c'è nulla di abbastanza piccolo, crea un'attività secondaria di un'attività più grande per avviarla (ovvero esegui alcuni dei lavori preliminari).

In alternativa, crea alcune attività che migliorano la base di codice. Non ho mai visto una base di codice che non potesse essere migliorata in alcun modo. Rivedi alcuni codici per aggiungere altri test unitari ecc.

Lavorare su elementi backlog di allungamento o futuri di sprint sembra essere la cosa comune da fare, il che ha molto senso se i tuoi elementi di backlog di sprint sono abbastanza piccoli e chiaramente definiti. Tuttavia, gli elementi di backlog che possono mettere il codice "completato" in uno stato "non più eseguito" devono essere evitati.

Se lo sprint è veramente finito, taggalo, preparalo per la consegna, consegnalo e metti i tuoi repository di codice sorgente nello stato "sprint successivo", quindi non c'è rischio che le modifiche allo sprint tardivo mettano a rischio la consegna.

Per noi uno Sprint non finisce mai presto. Abbiamo solo aumentato la nostra velocità o risolto il problema in un modo che ci consente di svolgere più lavoro nello sprint.

Dicendo che abbiamo sempre un arretrato di articoli che hanno la priorità in ordine di importanza dai nostri proprietari di prodotti. Quando qualsiasi squadra può inserire più lavoro nello sprint, è molto facile per loro vedere cosa fare dopo nella lista che si adatterà positivamente al tempo rimanente degli sprint data la loro velocità.

Ciò evita eventuali tempi di inattività del gruppo in attesa di discussioni con il Product Owner / Scrum Master su ciò che dovrebbe essere fatto in seguito. I nostri proprietari di prodotti e Scrum Master rimangono in cima a questo elenco, quindi c'è sempre più lavoro in attesa di essere inserito nello sprint successivo (o in quello attuale se il tempo lo consente).

Quello che il mio team fa è estrarre compiti dal backlog che sono ragionevolmente abbastanza piccoli da completare rispetto a quanto presto abbiamo finito. Se abbiamo finito con quello , diamo il nostro tempo team QA di raggiungere con loro test, e gli sviluppatori di ottenere un "giorno libero" - possiamo usare questo per esaminare altre questioni non legate allo sprint corrente, argomenti che vogliamo per ricercare, configurare / riconfigurare i nostri ambienti, ecc.

Non dedicare un sacco di lavoro solo perché hai finito presto. Attieniti a ciò che la tua squadra si è impegnata a fare in questo sprint e, se il lavoro extra è finito, è un vantaggio straordinario.

Incoraggerei slack da utilizzare per il miglioramento personale. Certo, raccogli storie dal backlog, ma assicurati di trascorrere un po 'di tempo su te stesso: impara una nuova lingua, esercita la tua arte con un kata, rifatti alcune cose, modifica, perfeziona o scrivi nuovi strumenti per aiutarti, andare e parlare a un stakeholder, collega o cliente, scopri cosa fa il tuo team di controllo qualità, prenditi del tempo per capire come funziona il tuo processo di UX.

C'è un enorme elenco di cose che puoi fare che forniranno valore alla tua attività e a te stesso E miglioreranno la tua velocità o la quantità di valore di qualità che fornisci che non comporta estrarre cose da un arretrato, provale prima.