KIMISUITE 7 min di lettura

Come gestire standup brevi e pianificare sprint realistici

Agende con tempi definiti, uno standup di 15 minuti con domande sempre nuove, story point prima della pianificazione e una previsione dello sprint basata sulla tua velocity e capacità, con un esempio pratico.

Come gestire standup brevi e pianificare sprint realistici

Le riunioni di team brevi e utili hanno tre cose in comune: un'agenda scritta con un tempo assegnato a ogni punto, una fine chiara e un risultato su cui qualcuno agisce. Una pianificazione dello sprint realistica ne ha una in più: il team si impegna su ciò che gli sprint recenti dicono che può fare, tenendo conto di chi è effettivamente disponibile, non su ciò che spera di fare.

La maggior parte dei team non parte con riunioni lunghe, ci arriva un po' alla volta: lo standup diventa un resoconto sullo stato dei lavori, i problemi si risolvono in cerchio mentre sei persone aspettano e la pianificazione si trasforma in una trattativa vinta dalla stima più ottimista. Questa guida illustra le soluzioni in quattro passaggi, usando quattro strumenti gratuiti su kimisuite.com. Nessuno richiede un account.

Passaggio 1: scrivi l'agenda prima di inviare l'invito

Il Meeting Agenda Generator offre sei modelli: daily standup, retrospettiva dello sprint, all-hands, 1:1, sales discovery call e kickoff di progetto. Inserisci un titolo, la durata dello slot e il facilitatore, poi copi o scarichi il risultato in formato markdown.

Il modello per lo standup è questo:

  1. Ieri: successi e ostacoli (5 min)
  2. Oggi: priorità (5 min)
  3. Blocchi e richieste (5 min)
  4. Una cosa che nessuno sa (un giro da un minuto)

Il modello per la retrospettiva dura 42 minuti: preparare il contesto (5), cosa è andato bene (10), cosa non è andato bene (10), azioni concrete, con un responsabile e una scadenza (15), e un rapido check dell'energia da 1 a 5 (2).

Un dettaglio utile da sapere: i tempi delle sezioni sono fissi per ogni modello. La durata che inserisci compare nell'intestazione, ma le sezioni non vengono riproporzionate. Se lo slot della retro è di 30 minuti, accorciale a mano prima di inviare l'invito. È proprio questo il punto: decidi in anticipo a cosa dedicare meno tempo.

Passaggio 2: mantieni lo standup entro 15 minuti

La Scrum Guide (versione di novembre 2020, scrumguides.org) descrive il Daily Scrum come "un evento di 15 minuti per i Developer", che si tiene "alla stessa ora e nello stesso luogo ogni giorno lavorativo dello Sprint". Il suo scopo è ispezionare i progressi verso lo Sprint Goal e adattare il piano per il lavoro successivo.

La stessa guida afferma anche che i Developer "possono scegliere la struttura e le tecniche che preferiscono". Le tre domande classiche sono un'abitudine, non una regola. Se "cosa hai fatto ieri?" è diventato un elenco recitato a memoria, cambia la domanda.

Qui ti aiuta lo Standup Question Generator. Sceglie da 1 a 10 domande casuali da una delle quattro raccolte: icebreaker, retrospettiva, approfondimento e divertimento. Apri lo standup con una domanda icebreaker una volta a settimana, oppure porta alla retrospettiva domande come "Dove hai perso più tempo?" o "Cosa dobbiamo SMETTERE di fare?".

Passaggio 3: stima le story prima della pianificazione

La pianificazione è più rapida quando le story hanno già una dimensione. Lo Story Point Estimator è una versione individuale del planning poker. Scegli Fibonacci (1, 2, 3, 5, 8, 13, 21, 40, 100) o le taglie T-shirt (da XS a XXL, più "?"), scrivi la story, scegli una carta e imposta la tua sicurezza su bassa, media o alta. Le stime finiscono in un elenco progressivo con il totale dei punti.

La parte utile sono le indicazioni sotto ogni carta. Un 13 mostra "Grande · scomponila prima di impegnarti", un 21 "Troppo grande · dividila in story più piccole" e "?" significa che ti servono più informazioni prima di stimare. Se ti ritrovi a scegliere 13 o più, la story non è pronta per lo sprint.

Le stime individuali sono un punto di partenza. Il team ne discute comunque, perché una persona da sola non sa ciò che sanno gli altri.

Passaggio 4: prevedi lo sprint in base alla tua velocity

La Scrum Guide non parla di velocity né di story point. Afferma però che più i Developer conoscono "le loro prestazioni passate, la loro capacità futura e la loro Definition of Done, più saranno sicuri delle loro previsioni sullo Sprint". La velocity, cioè i punti completati da un team per sprint, è un modo comune per misurarlo.

Il Sprint Velocity Calculator prende i tuoi ultimi tre sprint e la capacità per il prossimo, in percentuale, e restituisce:

  • La media dei tre sprint
  • Un trend: in crescita se l'ultimo sprint è stato superiore di oltre il 10 percento al precedente, in calo se è stato inferiore di oltre il 10 percento, altrimenti stabile
  • Una previsione: la media moltiplicata per la tua capacità
  • Quanti sprint servono per completare 50 punti con quella previsione

Un esempio pratico

Un team di cinque persone ha completato 24, 31 e 27 punti negli ultimi tre sprint. Una persona è in ferie per tutto il prossimo sprint, quindi la capacità è dell'80 percento.

  1. Media: (24 + 31 + 27) / 3 = 27,3 punti
  2. Trend: 27 è inferiore di oltre il 10 percento a 31, quindi il calcolatore mostra "In calo — indaga sugli ostacoli"
  3. Previsione: 27,3 x 0,8 = 21,8 punti
  4. Sprint per completare 50 punti: 50 / 21,8 = 2,3, arrotondato per eccesso a 3

Ora prendi le story stimate nel passaggio 3: 8, 5, 5, 3 e 2 punti, 23 in totale. È più della previsione di 21,8. Il piano onesto è 8 + 5 + 5 + 3 = 21 punti, con la story da 2 punti come prima da aggiungere se il team finisce in anticipo.

Il trend confronta solo gli ultimi due sprint, quindi basta uno sprint difficile per far scattare "in calo". Prima di considerarlo un problema, chiedi nella retrospettiva cosa si è messo di mezzo. E non confrontare mai la velocity tra team diversi: i punti di ogni team hanno un significato diverso.

Il ruolo di KIMISUITE

Gli strumenti funzionano anche da soli. Se vuoi riunioni e sprint board in un unico posto, due app KIMISUITE coprono i passaggi descritti sopra.

Meeting Hub gestisce videoriunioni a cui gli ospiti partecipano dal browser tramite un link. Quando pianifichi una riunione, puoi incollare l'agenda nella descrizione. Durante la chiamata, il menu Strumenti include un timer (1, 5, 10, 15, 30 minuti o personalizzato) visibile a tutti, che diventa rosso a 0:00. Un sondaggio con due o più opzioni aiuta la retro a decidere quale azione affrontare per prima. Dopo la riunione, la trascrizione è scaricabile con tutti i piani, mentre con Pro ed Enterprise un riepilogo AI elenca le azioni, con responsabili e scadenze, e le decisioni prese.

Task Hub ospita lo sprint vero e proprio. Il modello Engineering Sprint crea liste, etichette e schede di esempio per una nuova board. Dal piano Grow in su puoi aggiungere campi personalizzati, come un campo numerico, e impostare dipendenze, così una scheda può mostrare cosa blocca o da cosa è bloccata. Con il piano Business, AI Task può trasformare il riepilogo e la trascrizione di una riunione conclusa in Meeting Hub in schede proposte, che puoi verificare prima che vengano create. Per saperne di più leggi Task Hub: da una nota vocale a una task board.

Entrambe le app si trovano nello stesso workspace KIMISUITE, fatturato per workspace e non per utente. Per capire cosa significa per un team, consulta prezzo per workspace, non per utente. Ogni app include una prova di 14 giorni.

FAQ

E se il nostro standup continua a superare i 15 minuti?

Sposta altrove la risoluzione dei problemi. Quando un argomento richiede più di un minuto, nominalo, indica le due persone che devono parlarne e lascia che si incontrino subito dopo.

Dobbiamo usare per forza le tre domande dello standup?

No. La Scrum Guide del 2020 lascia ai Developer la scelta della struttura, purché la riunione ispezioni i progressi verso lo Sprint Goal e adatti il piano. Una domanda diversa ogni settimana evita che il giro diventi un resoconto.

Quanti sprint servono per calcolare la velocity?

Lo Sprint Velocity Calculator usa gli ultimi tre. Con meno sprint la media è poco affidabile; sprint molto vecchi descrivono un team che nel frattempo potrebbe essere cambiato.

Quale capacità devo inserire se qualcuno è assente per una parte dello sprint?

Stima la quota di giorni lavorativi del team effettivamente disponibili. In un team di cinque, una persona assente per l'intero sprint corrisponde all'80 percento. Una persona assente per tre giorni in uno sprint di dieci giorni significa 47 giorni-persona su 50, quindi circa il 94 percento.

Pianifica il tuo prossimo sprint con Task Hub