Che cos’è lo Scrumban?

Che cos’è davvero lo Scrumban

Lo Scrumban tiene le parti di Kanban e Scrum che si guadagnano il posto, e lascia il resto. Dal Kanban prende la bacheca visiva, il flusso a colonne e un limite esplicito a quanto lavoro è in corso — le cose che rendono leggibile il flusso. Dallo Scrum prende lo sprint a tempo — la cosa che trasforma un backlog in un piano.

Quello che salta: gli standup quotidiani, le riunioni di grooming, le cerimonie degli story point, la retrospettiva come rito. Funzionano per dieci ingegneri in un’organizzazione rodata; non funzionano per chi fonda da solo e prova a consegnare di sabato.

Il nome viene da Corey Ladas, che nel suo saggio e poi nel libro Scrumban ha descritto come i team Scrum possano passare dalle iterazioni fisse a un flusso a trazione (pull).

Scrumban vs Kanban vs Scrum: le differenze

I tre metodi differiscono soprattutto in due cose: se il lavoro si pianifica in blocchi di tempo fissi, e quanto processo circonda la bacheca.

Fonti: la Scrum Guide per sprint, ruoli ed eventi; la Kanban Guide per il flusso e i limiti al lavoro in corso.

Com’è fatta una bacheca Scrumban?

Una bacheca Scrumban è una bacheca Kanban con sopra uno sprint. Le colonne mostrano dove si trova il lavoro; lo sprint dice di quale parte del backlog si occupa questa settimana. Una bacheca minima ha quattro colonne:

• Backlog — tutto quello che potresti fare. Disordinato in fondo, ordinato in cima.
• Todo — quello che hai deciso di fare dopo. Piccolo apposta: quando si svuota, è il segnale che è ora di pianificare.
• Doing — ciò su cui qualcuno (una persona o un agente IA) sta lavorando in questo momento.
• Done — il lavoro finito. Svuotato o archiviato a fine sprint.

Come si imposta una bacheca Scrumban?

1. Crea le quattro colonne: Backlog, Todo, Doing, Done.
2. Metti in Backlog tutto quello che sai di dover fare. Non ordinare tutto — ordina la cima.
3. Decidi quanto può stare in Doing contemporaneamente. Per una persona, una o due cose; per un piccolo team, circa una a testa.
4. Scegli la durata dello sprint — una o due settimane — e scrivi per esso un obiettivo di una frase. Porta in Todo solo ciò che serve a quell’obiettivo.
5. Lavora a trazione: quando qualcosa in Doing è finito, prendi la scheda successiva dalla cima di Todo. Nessuno spinge lavoro addosso a nessuno.
6. Pianifica quando Todo si svuota, non in base al calendario. A fine sprint guarda cosa è stato fatto e cosa no, poi inizia il successivo.

Perché Weft sceglie lo Scrumban

Weft esiste perché la maggior parte dei gestori di attività è tagliata su uno di due estremi: o un’app di to-do solitaria (lista infinita, nessuna cadenza) o una suite Agile da cinquanta persone (processo da gestire per chi fonda da solo). Lo Scrumban sta esattamente nel mezzo — abbastanza struttura da imporre una consegna settimanale o quindicinale, non così tanta da passare il giorno della consegna ad amministrarla.

Come lo implementa Weft

• Quattro colonne di base: Backlog, Todo, Doing, Done. Il lavoro in corso è limitato da ciò che aspetta te, non da un numero per colonna. La Kanban Guide considera una regola esplicita per limitare il lavoro in corso parte della definizione del flusso di lavoro, così che i nuovi elementi entrino solo quando si libera capacità.
• Un solo sprint attivo per volta, con un obiettivo facoltativo. Gli sprint sono facoltativi — saltali se ti basta il Kanban puro. La Scrum Guide definisce gli Sprint come eventi di durata fissa di un mese o meno, e il nuovo Sprint inizia subito dopo la conclusione del precedente.
• Le attività hanno priorità, stima, scadenza e un collegamento facoltativo a uno sprint. Niente epiche, niente workflow, niente campi personalizzati.
• Il tempo di ciclo parte quando un’attività entra in una colonna con semantic="doing" e finisce in "done". I numeri vengono da un uso onesto, non da un’aritmetica di story point.

Scrumban con gli agenti IA

È la trazione a far funzionare lo Scrumban anche per gli agenti IA. Un agente collegato a Weft tramite MCP prende da solo la scheda successiva: start_task la reclama, così un secondo agente non può prendere la stessa scheda, e complete_task la chiude con ciò che è stato fatto e le prove. Quando a un agente serve una decisione, la chiede a te invece di tirare a indovinare — e finché troppo lavoro finito aspetta te, gli agenti smettono di iniziare nuove attività. È il limite Kanban al lavoro in corso, applicato all’unica risorsa che non scala: la tua attenzione.

Quando lo Scrumban non è il metodo giusto

• Fai girare più team Scrum in parallelo. La Scrum Guide indica per uno Scrum Team in genere 10 persone o meno, e dice che i prodotti più grandi vanno organizzati in più Scrum Team che condividono un unico Product Goal e un unico Product Backlog. Rendicontazione a livello di programma, velocity condivisa, dipendenze tra team — lì lo Scrum completo in Jira si guadagna il costo. La Nexus Guide è scritta per questa situazione: più Scrum Team che lavorano su un unico Product Backlog, con pratiche aggiuntive per far emergere e risolvere le dipendenze tra team.
• Fai solo supporto o operatività continua. Non serve nessuna cadenza a sprint — il Kanban puro o un sistema di ticket va meglio.
• Ti servono diagrammi di Gantt e cronoprogrammi. Lo Scrumban è centrato sugli sprint, non sui grafi di dipendenze.

Domande sullo Scrumban