Scrum: short VS long sprint

Penso che tu stia guardando un po 'indietro. La velocità è un effetto secondario del lavoro svolto dalla tua squadra. È non un fattore causale, ad es. è qualcosa che misura e non è qualcosa che puoi modificare direttamente.

Questa spiegazione della velocità ha una boccata rilevante per la tua domanda.

The simplest way to define velocity is: the number or user stories a team/project can do in one sprint

E con questa definizione, uno sprint più lungo significa più tempo per lo sviluppo per sprint e quindi un maggior numero di velocità.

relativa tra uno sprint di 2 settimane o di 3 settimane è una domanda leggermente diversa. I costi generali delle cerimonie di progetto possono influire su quanto si può fare perché c'è meno tempo complessivo disponibile. Considera questo calcolo come un modo per identificare le ore di sviluppo disponibili in uno sprint.

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

CeremonyOverhead è generalmente riparato. Riduci il DaysInSprint e puoi vedere come avrai meno tempo a disposizione per lo sviluppo durante lo sprint. Usando un semplice esempio di 1 dev, ecco i numeri per alcune lunghezze di sprint.

1 week:
((8 * 5) - 4) *.8 = 28.8 hours or 5.76 hours per day.
2 weeks:
((8 * 10) - 4) *.8 = 60.8 hours or 6.08 hours per day.
3 weeks:
((8 * 15) - 4) *.8 = 92.8 hours or 6.18 hours per day.

La risposta "ovvia" è che gli sprint più lunghi sono migliori. Il problema con la risposta ovvia è che ignora l'impatto positivo dei loop di feedback. Temperate i pensieri riguardo a quel calcolo con una prospettiva generale su ciò che Agile dovrebbe portare al processo di sviluppo.

Sospetto che il tuo problema principale sia che le tue storie utente non sono definite come potrebbero essere. Quella mancanza di comprensione di ciò che è richiesto è il vero impedimento per ottenere il lavoro compiuto.

On the other hand, there are a lot of disadvantages such as ceremonies (planning, retrospective) and so on

Questa è una grande bandiera rossa. Se la vedi come una cerimonia piuttosto che un veicolo essenziale che serve il processo di lavoro e il suo miglioramento, probabilmente lavorare su questo ha più guadagno che giocare con la lunghezza dello sprint.

Il processo è nelle tue mani (nel senso della squadra). Dovresti inseguire le idee più belle, se necessario sperimentare e aggiustare. Stavamo facendo 2 settimane, poi alla fine passò a 3 settimane e ha funzionato meglio. Ma a volte basta impostare la lunghezza in base alla stima per l'ambito. Sì, sono consapevole dell'idea di "lunghezza uguale", ma non è un dogma e potrebbe non adattarsi perfettamente ad un progetto di vita reale. E avere un obiettivo di sprint chiaro ed evidente può servire meglio.

La lunghezza corretta non è in realtà qualcosa che può essere dedotta dall'esterno. Sei lì per conoscere i fattori rilevanti. Alla pianificazione puoi iniziare con "ok, cosa possiamo fare nelle prossime X settimane". O invece "quale sarebbe il prossimo incremento sensibile". In ogni caso la pianificazione di quest'ultimo è buona, quindi guarda che tempo ci vorrebbe. E parte che in uno o più sprint.

Fino a te. Prova entrambi, guarda cosa funziona. Usa quello.

La migliore "sprint" agile che abbia mai usato è stata di 6 settimane. Abbiamo fatto così tanto - ma dovevamo solo consegnare al cliente in base a quel programma. Non abbiamo usato le attività, preferendo lavorare sullo stile di lavoro della user story.

Dipende da cosa descrivi una "nuova squadra".

In effetti, la velocità di una squadra dipende da molti parametri tra molti (es .: juniores, anziani ?, nuovi arrivati ?, tensioni tra membri della squadra? ecc.).

Quindi anche la lunghezza sprint "ideale" è legata a questi parametri.

Ad ogni modo, non esiste una soluzione pronta per questo, l'unico modo è provarlo con il team stesso, e anche prendere in considerazione il miglior adattamento medio per tutti i membri del team.

Metto in dubbio il tuo suggerimento di un "ciclo di feedback più breve". Il tuo team dovrebbe lavorare con i tuoi clienti su base giornaliera - il feedback non dovrebbe aspettare per Sprint Review e Retrospective. Prova, codifica, progetta e ottieni un feedback immediatamente .

Personalmente mi piace lo sprint di tre settimane perché la settimana centrale consente al team un po 'di tempo di "flusso". Cioè, c'è sempre un sacco di tempo che risveglia la prima settimana (imparando cosa diavolo significano queste nuove storie) e alcuni completando l'ultimo (prepping per la recensione). Una settimana intermedia per produrre semplicemente software di lavoro è davvero una bella cosa da avere.

Seguendo questa logica, le scorse di quattro settimane avrebbero ancora più senso. Tuttavia, il senso di urgenza può essere perso se si avvia l'estensione degli sprint. Inoltre, c'è davvero una porzione relativamente piccola di informazioni che una persona o una squadra possono afferrare e tenere nel loro pensiero cosciente in una volta: più lungo è lo sprint, più cose su cui stai cercando di concentrarti, che possono rendere le cose più difficili invece che Più facile. Inoltre, è più difficile giudicare quali fattori esterni si insinueranno se estendete le cose troppo lontano.

Dato che hai chiesto informazioni su un nuovo nuovo team, volevo aggiungere alcune considerazioni. Ho lavorato con Scrum e altri metodi Agile per oltre 15 anni e ora consiglio sempre che i nuovi team inizino con Sprints da 1 settimana. Ci sono tre ragioni critiche per questo:

• Gli Sprint brevi aiutano i team a raggiungere uno stato ad alte prestazioni più velocemente. Long Sprints di solito significa che ci vogliono 18 mesi a due anni per arrivare a quello stato. Brevi Sprint di una settimana aiutano una squadra a raggiungere lo stato ad alte prestazioni in soli due o tre mesi. Ovviamente, anche altre cose devono essere messe in atto per raggiungere alte prestazioni (vedi "La saggezza delle squadre" di Katzenbach e Smith).
• Come altri hanno già detto, uno Sprint più corto aumenta il ciclo di feedback. Uno Sprint di una settimana lungo sembra essere ottimale per la maggior parte delle squadre che sviluppano software o sviluppano prodotti. Il feedback dovrebbe essere principalmente durante la Sprint Review, che dovrebbe sostituire la tradizionale procedura UAT.
• Infine, gli Sprint più brevi mettono sotto pressione la tua squadra per affrontare gli ostacoli organizzativi alla consegna frequente. Questa pressione all'inizio è molto scomoda, ma è essenziale per migliorare i processi di sviluppo generali, compresi pianificazione, conformità, rilasci, ecc.

Ho scritto un articolo chiamato 21 suggerimenti per Scelta di una lunghezza di Sprint che potrebbe essere di interesse.