Scrum vs Kanban: le differenze e quale si adatta a un piccolo team
Di Andrei Finogeev, fondatore di Weft ·
Scrum pianifica il lavoro in sprint fissi di un mese o meno, con tre responsabilità (Product Owner, Scrum Master, Developers) e quattro eventi in ogni sprint. Kanban non ha sprint né ruoli prescritti: il lavoro scorre in modo continuo su una bacheca e il team limita esplicitamente quanto lavoro è in corso. Scegli Scrum quando un team di più persone ha bisogno di un ritmo di consegna fisso e di un obiettivo stabile per ciclo; scegli Kanban quando il lavoro arriva in modo imprevedibile e le priorità cambiano ogni giorno. Lo Scrumban sta nel mezzo: il flusso del Kanban, con gli sprint solo dove aiutano.
Scrum vs Kanban vs Scrumban: lo schema
Scrum come definito dalla Guida a Scrum 2020, Kanban come definito dalla Guida a Kanban (v2025.5). Lo Scrumban non ha una guida ufficiale; la colonna descrive come viene praticato di solito.
| Scrum | Kanban | Scrumban | |
|---|---|---|---|
| Cadenza | Sprint fissi di un mese o meno, uno dopo l’altro | Flusso continuo, nessuna iterazione | Flusso continuo; sprint facoltativi, di solito di una o due settimane |
| Ruoli | Product Owner, Scrum Master, Developers | Nessuno prescritto | Nessuno prescritto; spesso una persona è responsabile delle priorità |
| Riunioni | Sprint Planning, Daily Scrum (15 min), Sprint Review, Sprint Retrospective | Nessuna prescritta | Solo quelle che il team trova utili, di solito una pianificazione e una revisione |
| Cosa limita il lavoro | Ciò su cui il team si impegna per lo sprint | Un limite esplicito al lavoro in corso | Un limite al lavoro in corso, più l’obiettivo dello sprint se c’è |
| Cambiare il perimetro a metà ciclo | Lo Sprint Goal resta fisso; lo Sprint Backlog può essere raffinato | In qualsiasi momento: l’elemento successivo viene tirato quando c’è spazio | In qualsiasi momento; l’obiettivo dello sprint è un traguardo, non un vincolo |
| Misure principali | Avanzamento verso lo Sprint Goal e il Product Goal | Lavoro in corso, throughput, età degli elementi, tempo di ciclo | Di solito le misure di flusso del Kanban |
| Bacheca | Facoltativa; azzerata a ogni sprint | Il cuore del metodo; permanente | Permanente; uno sprint ne è una porzione |
| Ideale per | Team di prodotto fino a una decina di persone che lavorano verso un obiettivo | Supporto, operations e chiunque riceva lavoro non pianificato | Piccoli team e founder solitari che vogliono flusso e un obiettivo a breve termine |
Cos’è Scrum
Scrum è stato presentato per la prima volta da Ken Schwaber e Jeff Sutherland alla conferenza OOPSLA nel 1995; le regole attuali sono quelle della Guida a Scrum 2020. Uno Scrum Team ha di solito dieci persone o meno e lavora in sprint: eventi di durata fissa di un mese o meno, che iniziano subito dopo la fine del precedente.
Ogni sprint ha quattro eventi. Lo Sprint Planning (al massimo otto ore per uno sprint di un mese) stabilisce lo Sprint Goal e sceglie il lavoro. Il Daily Scrum è un punto di 15 minuti per i Developers. La Sprint Review (al massimo quattro ore) mostra il risultato agli stakeholder, e la Sprint Retrospective (al massimo tre ore) esamina come ha lavorato il team.
Scrum ha tre artefatti, ognuno con un impegno: il Product Backlog (il Product Goal), lo Sprint Backlog (lo Sprint Goal) e l’Increment (la Definition of Done).
Cos’è Kanban
La Guida a Kanban definisce Kanban come «una strategia per ottimizzare il flusso di valore attraverso un processo». Nasce dal sistema di cartellini che Toyota usava per segnalare quando produrre di più, ed è stato adattato al lavoro della conoscenza negli anni 2000.
Ha tre pratiche: definire e visualizzare il flusso di lavoro, gestire attivamente gli elementi al suo interno e migliorarlo. L’unica regola rigida è che le persone nel sistema controllano esplicitamente quanti elementi sono in corso tra l’inizio e la fine: il limite al lavoro in corso (WIP, work in progress).
Kanban non prescrive ruoli, sprint né riunioni. Segue quattro misure di flusso: lavoro in corso, throughput, età degli elementi e tempo di ciclo.
Pro e contro
Scrum
- Un ritmo fisso: tutti sanno quando è atteso il prossimo risultato
- Un obiettivo chiaro per sprint evita che il team vada alla deriva
- Momenti previsti per ispezionare il prodotto e il processo
- Quattro eventi per sprint sono un costo di tempo reale per un team di due o tre persone
- Il lavoro urgente o aspetta lo sprint successivo o rompe il piano
- Serve qualcuno per ogni responsabilità, e un founder da solo non può dividersi
Kanban
- Parte sulla bacheca che hai già; non c’è altro da introdurre che un limite WIP
- Il nuovo lavoro può essere tirato dentro in qualsiasi momento
- Le misure di flusso mostrano dove il lavoro si blocca
- Nessuna scadenza né obiettivo integrati, quindi il lavoro lungo può andare alla deriva
- Senza un limite WIP è solo una lista di cose da fare con le colonne
- La pianificazione in anticipo è lasciata interamente al team
Quale scegliere
- Un team di prodotto da cinque a dieci persone con una roadmap stabile
- Scrum. Gli eventi si ripagano quando più persone devono accordarsi su un obiettivo ogni due o tre settimane.
- Supporto, operations o un team che vive di richieste in arrivo
- Kanban. Il lavoro arriva quando arriva; un limite WIP e una colonna Done chiara contano più di un piano di sprint.
- Un founder solitario o un team da due a cinque persone
- Scrumban. Tieni una bacheca continua con un limite WIP e usa uno sprint di una o due settimane come obiettivo a breve termine, senza l’intero set di eventi Scrum.
Scrumban: la via di mezzo
Corey Ladas ha descritto lo Scrumban come un modo per i team Scrum di passare a un flusso di tipo pull. In pratica è una bacheca Kanban con limiti WIP che non si azzera mai, più sprint come time-box facoltativi che raggruppano una parte del lavoro. La nostra guida completa spiega le regole e come impostare la bacheca: Cos’è lo Scrumban?
Quando gli agenti IA fanno parte del lavoro
Se ChatGPT, Claude, Cursor o Codex prendono in carico attività per te, gli eventi di Scrum non hanno nessuno che vi partecipi: un agente non viene allo stand-up. Quello che conta ancora è ciò che offre il Kanban: una bacheca che mostra cosa è in corso, un limite WIP perché non si avviino dieci attività insieme e una regola chiara per quando una scheda è finita.
Si sposta anche il collo di bottiglia. Gli agenti finiscono il lavoro in fretta, e il passaggio lento diventa la tua revisione di ciò che hanno fatto. Un limite a quanto lavoro finito può aspettarti è un limite WIP sulla colonna umana.
Weft è una bacheca Scrumban costruita per questo: colonne, sprint facoltativi, un limite a quanto lavoro finito può attendere la tua revisione, e un’IA che prende in carico un’attività prima di iniziare, riporta i progressi e si ferma a chiederti quando solo tu puoi decidere.
Domande
Scrum e Kanban sono la stessa cosa?
No. Sono entrambi approcci agili ed entrambi usano spesso una bacheca, ma Scrum pianifica il lavoro in sprint fissi con ruoli ed eventi definiti, mentre Kanban ha un flusso continuo, nessun ruolo prescritto e un limite esplicito al lavoro in corso.
In Kanban si fanno gli sprint?
Non nel Kanban in sé: la Guida a Kanban non prescrive iterazioni. I team che aggiungono sprint a una bacheca Kanban di solito stanno facendo Scrumban.
Come funziona uno sprint Scrum?
Uno sprint è un periodo fisso di un mese o meno. Inizia con lo Sprint Planning, che stabilisce lo Sprint Goal; i Developers si incontrano per un Daily Scrum di 15 minuti; finisce con una Sprint Review del risultato e una Sprint Retrospective sul processo, e lo sprint successivo inizia subito.
Chi ha inventato lo Scrumban?
Il termine è attribuito a Corey Ladas, che ha descritto lo Scrumban in alcuni saggi e in un libro del 2009 come un modo per i team Scrum di passare a un flusso pull in stile Kanban.
Scrum è la stessa cosa di Agile?
No. Agile è l’insieme di valori e principi del Manifesto Agile del 2001; Scrum e Kanban sono due modi concreti di lavorare che li seguono.
Uno sviluppatore solitario può usare Scrum?
Non come è scritto: Scrum presuppone un team con tre responsabilità separate. Uno sviluppatore solitario di solito tiene le parti utili, un backlog e un breve obiettivo dello sprint, e gestisce la bacheca come Kanban — che è Scrumban.
Fonti
Letto il 11 novembre 2026.