Cos’è Kanban: board, WIP limit e flusso (e Scrum vs Kanban)

Cos’è Kanban: il metodo che rende visibile il flusso di lavoro

Kanban è un metodo per gestire il lavoro mostrando, in modo visivo, ogni attività mentre attraversa le sue fasi. La parola viene dal giapponese e significa “cartello” o “segnale visivo”: nasce nei sistemi produttivi Toyota e arriva poi al lavoro intellettuale grazie a David J. Anderson, che lo formalizza per il software e i servizi.

La sua promessa è semplice. Invece di pianificare blocchi di lavoro a tempo fisso, osservi come scorre quello che hai già in corso, individui dove si blocca e intervieni. Niente di magico, ma molto pratico.

La differenza più importante rispetto ad altri approcci è questa: Kanban è evolutivo. Parte da come lavori adesso, mappa il processo esistente e lo migliora a piccoli passi. Non impone ruoli nuovi, non prescrive eventi obbligatori, non chiede di riorganizzare il team dalla mattina alla sera. Ci si appoggia sopra al modo di lavorare attuale e lo si rende trasparente. Per chi gestisce progetti digitali con team già rodati, questa gradualità è spesso ciò che fa la differenza tra un cambiamento che attecchisce e uno che viene rigettato.

I quattro elementi di una board Kanban

La board è il cuore visivo del metodo, ma una board fatta bene è molto più di qualche colonna con dei post-it sopra. Sono quattro gli elementi che la rendono uno strumento di gestione, non solo una lista decorata.

1. Le colonne (gli stati del lavoro)

Ogni colonna rappresenta una fase reale che un’attività attraversa: da fare, in lavorazione, in revisione, fatto. La regola d’oro è che le colonne devono rispecchiare il processo che esiste davvero, non quello ideale che vorresti avere. Se nel tuo flusso c’è sempre un passaggio di approvazione del cliente, quella colonna deve comparire sulla board. Mappare il processo reale è il primo atto di onestà di Kanban.

2. Le schede (le unità di lavoro)

Ogni scheda è un pezzo di lavoro: una funzionalità, un bug, un task, una richiesta. Sulla scheda metti le informazioni che servono a capirla a colpo d’occhio: titolo, responsabile, eventuale scadenza, tipo di lavoro. Le schede si spostano da sinistra a destra man mano che il lavoro avanza, ed è proprio quel movimento a raccontare lo stato del progetto meglio di qualsiasi report.

3. Le policy esplicite

Questo è l’elemento che molti dimenticano, ed è quello che separa una board seria da una bacheca casuale. Una policy esplicita dichiara, nero su bianco, quando una scheda può passare alla colonna successiva. Cosa significa “fatto” per la colonna In lavorazione? Magari: codice scritto, test passati, pull request aperta. Scrivere queste regole accanto alle colonne elimina le discussioni infinite su cosa sia davvero pronto.

4. Le swimlane (le corsie orizzontali)

Le swimlane dividono la board in fasce orizzontali per separare flussi diversi: per esempio una corsia per le attività urgenti, una per il lavoro pianificato, una per la manutenzione. In questo modo a una sola occhiata distingui ciò che corre da ciò che può aspettare, senza mischiare tutto nello stesso calderone.

Il WIP limit: il vincolo che fa funzionare tutto

Se dovessi togliere ogni cosa da Kanban e tenerne una sola, terrei il WIP limit. WIP sta per Work In Progress, lavoro in corso, e il limite è un numero massimo di schede che possono stare contemporaneamente in una colonna.

Sembra una restrizione, e lo è. Ma è una restrizione liberatoria. Se la colonna In lavorazione ha un limite di tre, quando ci sono già tre schede dentro nessuno può iniziarne una quarta. Bisogna prima portarne una a destra, cioè finire qualcosa. Kanban smette di premiare chi inizia tante cose e inizia a premiare chi le chiude.

Come si imposta un WIP limit per colonna

Non esiste un numero universale. Un punto di partenza ragionevole, suggerito da chi pratica il metodo, è legare il limite alle persone disponibili in quella fase: per esempio circa una scheda e mezza per persona, arrotondando. Con un team di quattro sviluppatori, un limite di sei sulla colonna In lavorazione è un buon esperimento iniziale. Poi si osserva e si corregge: se la colonna è sempre satura e il lavoro ristagna, il limite è troppo basso o c’è un collo di bottiglia a valle; se non si raggiunge mai, è troppo alto e non sta creando alcuna tensione utile.

Il consiglio pratico è abbassare i limiti con coraggio. Quasi sempre i team partono con numeri troppo alti per paura di restare fermi, e quella paura è esattamente il problema che Kanban vuole mettere in luce.

Perché il WIP limit riduce il context switching

Quando una persona ha cinque attività aperte, passa la giornata a saltare dall’una all’altra. Ogni salto costa: bisogna ricaricare il contesto, ricordare dove eri rimasto, riprendere il filo. Secondo rilevazioni di settore 2025-2026 sulla produttività del lavoro intellettuale, il tempo perso in questi continui cambi di compito può erodere una quota significativa della giornata produttiva, con stime che in alcuni report arrivano fino a circa un quinto del tempo utile.

Limitando il lavoro in corso, riduci il numero di palline che ciascuno tiene in aria. Meno salti, meno contesto da ricaricare, più cose portate effettivamente a termine. Il WIP limit non rallenta il team: gli impedisce di rallentare se stesso.

Le metriche di flusso: misurare invece di indovinare

Kanban non chiede stime a vista. Misura il flusso reale e usa quei dati per fare previsioni. Quattro metriche bastano per iniziare.

• Lead time: il tempo che passa da quando una richiesta entra nel sistema (la metti in To Do) a quando è completata. È la metrica che vede il cliente, perché racconta quanto deve aspettare dal momento in cui chiede qualcosa.
• Cycle time: il tempo da quando il lavoro su una scheda inizia davvero (entra in Doing) a quando finisce. Misura l’efficienza del team una volta che mette le mani sull’attività, escludendo l’attesa in coda.
• Throughput: quante schede il team completa in un dato periodo, per esempio a settimana. È la velocità di consegna, ed è la base per qualsiasi previsione affidabile.
• Cumulative flow diagram: un grafico che impila nel tempo il numero di schede in ciascuno stato. Quando una banda colorata si allarga, lì il lavoro si sta accumulando: il diagramma ti mostra il collo di bottiglia prima ancora che tu lo senta.

La forza di queste metriche è che non si litiga su di esse. Sono numeri che escono dalla board stessa, non opinioni. E permettono di rispondere alla domanda che ogni stakeholder fa: “quando sarà pronto?”, con un intervallo basato su dati storici invece che su un desiderio.

Una board d’esempio: dove si nasconde il collo di bottiglia

Vediamo una board concreta con quattro colonne e i relativi WIP limit. Immagina un team di sviluppo digitale a metà settimana.

| TO DO        | DOING (3)    | REVIEW (2)   | DONE         |
|--------------|--------------|--------------|--------------|
| Landing v2   | API pagamenti| Fix login    | Email reset  |
| Report PDF   | Dashboard    | Filtro date  | Export CSV   |
| Notifiche    | Onboarding   |              | Header nuovo |
| Ricerca      |              |              | Footer       |
|              |              |              | Banner       |

A prima vista sembra tutto sotto controllo. Ma guarda meglio. La colonna Doing ha tre schede e il suo limite è tre: è satura. La colonna Review ne ha due con limite due: anche lei è piena. Risultato: nessuno può spostare una scheda da Doing a Review, perché Review non ha posto. E nessuno può iniziare la quarta scheda di To Do, perché Doing è bloccata.

Il collo di bottiglia è Review. Il lavoro arriva lì più velocemente di quanto venga revisionato e smaltito. Senza WIP limit non te ne saresti accorto: avresti continuato a sviluppare, accumulando schede in attesa di revisione e illudendoti di essere produttivo. Con i limiti, invece, il blocco diventa visibile subito e il segnale è chiaro: chi è libero in Doing non deve iniziare cose nuove, deve andare ad aiutare in Review. Kanban trasforma “siamo tutti occupati” in “ecco esattamente dove serve una mano”.

Scrum e Kanban a confronto

Scrum e Kanban vengono spesso messi in contrapposizione, ma rispondono a esigenze diverse. Scrum organizza il lavoro in cicli a tempo fisso, gli sprint, con ruoli e cerimonie definiti. Kanban gestisce un flusso continuo senza imporre struttura. Se vuoi approfondire il primo, abbiamo dedicato una guida completa a cos’è Scrum e come funziona. Qui mettiamo i due a confronto sui punti che contano davvero quando devi scegliere.

In pratica: Scrum dà ritmo e prevedibilità a chi sviluppa prodotti per obiettivi; Kanban dà fluidità a chi gestisce un flusso imprevedibile di richieste, come un team di supporto o di operations. Nessuno dei due è superiore in assoluto. Il punto è quale forma di lavoro stai gestendo, una distinzione che ricorda quella tra approcci a fasi e approcci iterativi che trattiamo in agile vs waterfall: quando usare l’uno o l’altro.

Scrumban: quando l’ibrido ha senso

Esiste una terza via che molti team adottano senza nemmeno chiamarla per nome: Scrumban. È l’innesto del WIP limit e della visualizzazione del flusso tipici di Kanban sulla struttura a sprint di Scrum, oppure l’introduzione graduale di alcune pratiche Scrum in un sistema Kanban.

Quando conviene? In genere in tre situazioni. Quando un team Scrum si accorge che la rigidità dello sprint mal si adatta a un carico di lavoro pieno di urgenze impreviste, e vuole più fluidità. Quando un team che parte da zero vuole l’ordine di Scrum ma teme di imporre troppa struttura tutta insieme. E quando si gestisce un mix di lavoro pianificabile e di richieste che arrivano a flusso, come spesso accade nei team di prodotto maturi che devono sviluppare e mantenere allo stesso tempo.

Scrumban non è un compromesso al ribasso. È il riconoscimento pragmatico che ritmo e flusso possono convivere, e che la scelta degli strumenti deve servire il lavoro, non un’ortodossia metodologica.

Da dove partire per padroneggiare il flusso

Capire Kanban sulla carta è facile. Farlo funzionare su un team reale, con WIP limit tarati, policy condivise e metriche lette nel modo giusto, è una competenza che si costruisce con metodo. Se vuoi acquisire le basi della gestione progetti agile partendo dalle fondamenta, il Scopri il corso Digital Project Manager Foundation è pensato esattamente per chi inizia. È un percorso on demand da 27 ore con accesso per 12 mesi, fruibile in modalità Community oppure Blended con una sessione di Q&A live a settimana, quindi interamente online e compatibile con i tuoi tempi. Include un simulatore, materiale didattico, una community, l’app dedicata e un attestato con badge a fine percorso. Ti prepara inoltre alla certificazione PSM I di Scrum.org, l’esame si sostiene esternamente e non è incluso nel corso, e una volta ottenuta quella credenziale resta valida senza scadenza. Non servono prerequisiti: è il punto di partenza ideale per costruire basi solide su Scrum, Kanban e tutto il resto.

FAQ

Kanban è un framework agile come Scrum?

Kanban è più un metodo che un framework: non prescrive ruoli né eventi e si applica sopra al processo esistente. Condivide con Scrum i valori agili di trasparenza e miglioramento continuo, ma li persegue in modo evolutivo invece che riorganizzando il team. Per questo i due possono anche convivere, come accade nello Scrumban.

Qual è un buon WIP limit per iniziare?

Non c’è un numero valido per tutti. Un buon esperimento di partenza è legare il limite alle persone attive nella fase, intorno a una scheda e mezza per persona, e poi correggere osservando la board. Se una colonna resta sempre satura, c’è un collo di bottiglia da affrontare; se non si riempie mai, il limite è troppo alto per essere utile.

Che differenza c’è tra lead time e cycle time?

Il lead time misura tutto il tempo dalla richiesta alla consegna, comprese le attese in coda, ed è la prospettiva del cliente. Il cycle time misura solo il tempo in cui il team lavora attivamente sulla scheda, dall’inizio della lavorazione alla fine. La differenza tra i due rivela quanto lavoro resta fermo in attesa.

Posso usare Kanban da solo, senza un team?

Sì. Una personal board con poche colonne e un WIP limit basso, anche uno o due, aiuta chiunque a smettere di iniziare troppe cose insieme e a portarne effettivamente a termine. Il principio che limita il lavoro in corso e riduce il context switching funziona identico, che tu sia un team di dieci persone o una sola.