Care e diferența reală dintre Kanban și Scrum?
Scrum livrează batch-uri (sprinturi) cu ceremonii fixe; Kanban livrează flux continuu cu limite de WIP. Aceeași echipă poate folosi unul, altul sau ambele — depinde de predictibilitatea cererii.
Diferența nu e "Kanban e mai simplu, Scrum e mai complex" — sunt două sisteme de management al fluxului de muncă cu ipoteze diferite despre cum vine cererea. Scrum funcționează când poți planifica scope-ul în iterații; Kanban funcționează când cererea e continuă și imprevizibilă (ex: support, mentenanță, ops). Multe echipe folosesc Scrum pentru feature work și Kanban pentru bug-uri și ops în paralel.
1. Iterații fixe vs flux continuu
Scrum împachetează munca în iterații (sprinturi) de 1-4 săptămâni. La începutul sprintului commit-ezi un scope, la sfârșit livrezi un increment. Există ceremonii fixe: planning, daily, review, retro.
Kanban nu are iterații. Munca curge continuu prin board: când un task se închide, intră altul. Nu commit-ezi scope pe perioadă fixă — commit-ezi pe item, când îl tragi în "In Progress". Cadența livrării e determinată de viteza fluxului, nu de calendar.
2. WIP limit: principiul central al Kanban
Kanban impune limite explicite pe câte task-uri pot fi în fiecare coloană simultan (Work In Progress limits). Dacă limita pentru "In Progress" e 3, al 4-lea task nu intră — echipa trebuie să termine unul existent înainte să tragă altul.
WIP limits forțează echipa să finalizeze ce a început înainte să apuce altceva nou — reduce dramatic context switching-ul, expune blocajele rapid și produce un flux mai rapid end-to-end. Scrum nu cere WIP limits explicite (deși echipele bune le folosesc oricum).
3. Roluri și ceremonii: dense vs minimale
Scrum vine cu roluri prescrise: Product Owner, Scrum Master, Development Team. Cu ceremonii prescrise: Sprint Planning, Daily Stand-up, Sprint Review, Sprint Retrospective.
Kanban nu prescrie roluri și nu cere ceremonii fixe. În practică echipele Kanban țin un daily stand-up scurt în jurul board-ului și o retrospectivă lunară, dar fără cadență prescrisă. Sistemul e mult mai ușor de adoptat incremental — poți "adăuga Kanban" peste un proces existent fără să schimbi structura echipei.
4. Estimare: story points vs cycle time
Scrum estimează în story points (mărime relativă) și măsoară velocity (SP livrate per sprint). Predictibilitatea pe scope vine din velocity istoric.
Kanban nu estimează — măsoară cycle time (de la "In Progress" la "Done") și throughput (task-uri livrate per săptămână). Predictibilitatea vine din distribuția cycle time-ului: "85% din task-urile noastre se închid în mai puțin de 5 zile". Pentru echipe de support sau mentenanță, acest model e mult mai util decât story points.
5. Când folosești care
Scrum: produs cu roadmap clar, echipă stabilă, scope previzibil pe 1-2 săptămâni înainte, stakeholderi care vor demo-uri regulate.
Kanban: support, operations, mentenanță, echipe care primesc cereri imprevizibile, fluxuri unde unitatea de muncă variază mult în dimensiune. Și hybrid: feature work pe Scrum, bug fixing pe Kanban în paralel, cu același backend și aceeași echipă — exact ce permite 4myprojects nativ.
Scrum și Kanban în același portal
Vezi același backlog ca board Kanban cu WIP limits sau ca sprint cu story points și burndown — un clic, fără să mute task-uri între tool-uri sau să rescrii fluxul.