Avere un limite su ogni colonna ti assicura che gli Item si spostino velocemente da una colonna all’altra, visto che questo è l’unico modo per inserire nuovi Item.

Il Pull system funziona in modo diverso, ovvero con un limite sul numero di elementi inseribili in ogni singola colonna della board, questo limite viene chiamato WIP Limit, ovvero Work in Progress Limit.

La principale differenza è che nel Kanban non esistono le sprint. Il processo di sviluppo è continuo.

Per tracciare i progressi si usa una board chiamata Scrum Board, Agile Board o per fare un po’ di casino Kanban Board.Di solito ci sono 4 colonne: To Do, Doing o Progress, Test o QA, Done. La premessa di tutto è che queste due metodologie non sono prescrittive per cui ogni team poi può decidere di aggiungere o rimuovere colonne in base alle proprie esigenze.Il Movimento ideale degli Item sulla scrumboard è da sinistra verso destra, se il movimento è al contrario c’è qualcosa che non va.

Questa parte è il Pull di cui stavamo parlando prima, ovvero gli item vengono “tirati” dal backlog e non “pushati” da qualcun altro.

Quello che accade tra il product backlog, ovvero la mega-lista di cose da fare, e il customer, ovvero l’utente che userà il tuo prodotto, è quello che distingue Scrum da Kanban.

Alcune caratteristiche del Product Backlog:Ogni Item in Backlog deve aggiungere valore all’utente finaleIl Backlog deve essere ordinato e prioritizzatoIl Backlog è un documento vivente. Il processo di revisione e modifica giornaliera del Backlog da parte del Product Owner si chiama Backlog GroomingI dettagli di ogni Item dipendono tipicamente dalla loro posizione sul Backlog: in alto tanti dettagli, in basso pochi dettagli.

Il Product Backlog è  la lista prioritizzata di tutto ciò che si vorrebbe fare (occhio a queste due parole!) all’interno del progetto. Qui sta una delle prime intuizioni semplicissime, ma geniali, dei due metodi.Il fatto che un Item sia in backlog non vuol dire che verrà sicuramente affrontato, sviluppato e rilasciato.

Secondo i principi dell’Agile, come abbiamo visto nel post precedente, il software viene consegnato al customer in piccoli pezzi che incrementano il valore del software progressivamente, inoltre il feedback dal customer viene preso costantemente in considerazione e diventa parte essenziale del ciclo di sviluppo.

n una cascata (waterfall), infatti, l’acqua cade sempre dall’alto verso il basso e così funziona nello sviluppo software Waterfall:Il responsabile di prodotto definisce i requisiti di tutto il progettoIl team di sviluppo realizza il progetto per interoIl progetto viene consegnato al customer tutto in una voltaTutto va nella stessa direzione. Dall’alto verso il basso. Sempre

As we advocate in our Agile Product Management overview, the more involved that a product manager is with the development team, the better. That involvement should be along the lines of a product owner who champions customer needs, the "why" of the product. When the involvement blurs into tasking, the "how" for a team, then there is a problem. Even with the best of intentions, this kind of utilization mindset tends to hide problems: defects, hand-offs, and unknowns. Interleaving scope and process tends toward locking scope, schedule, and quality. That's a recipe for failure.