Zespół może realizować Sprinty zgodnie ze Scrumem, regularnie prowadzić Daily Scrum i kończyć większość zaplanowanych zadań, a mimo to mieć słaby przepływ pracy. Kilkanaście elementów pozostaje jednocześnie rozpoczętych, code review tworzy kolejkę, testy kumulują się pod koniec Sprintu, a część zadań przechodzi do kolejnej iteracji.
Scrumban oraz praktyki Kanban stosowane w Scrumie pomagają spojrzeć na taki problem z perspektywy przepływu. Zamiast koncentrować się wyłącznie na ilości pracy zaplanowanej na Sprint, zespół obserwuje również, ile elementów rozpoczął, jak długo pozostają w toku i gdzie tworzą się wąskie gardła.
Nie trzeba przy tym rezygnować ze Sprint Goal, Sprint Review czy retrospektywy. Scrum.org wprost opisuje Kanban jako strategię, która może uzupełniać Scrum i pomagać optymalizować przepływ pracy w istniejącym frameworku.
Czym jest Scrumban?
Scrumban to podejście łączące elementy Scrum i Kanban.
Najczęściej zespół zachowuje część struktury Scruma — np. regularny rytm planowania, Sprinty, retrospektywy czy przeglądy — a jednocześnie wykorzystuje mechanizmy Kanban:
- wizualizację rzeczywistego workflow,
- ograniczanie Work in Progress,
- system pull,
- zarządzanie przepływem,
- metryki takie jak cycle time i throughput.
W aktualnych materiałach Atlassian i Scrum Alliance Scrumban jest opisywany jako podejście hybrydowe wykorzystujące strukturę Scrum oraz przepływ i limity WIP charakterystyczne dla Kanban.
W praktyce pod nazwą Scrumban mogą jednak kryć się bardzo różne sposoby pracy. Nie istnieje jeden oficjalny Scrumban Guide określający obowiązkowe role, wydarzenia i artefakty.
Dlatego warto rozróżnić dwa podejścia.
Scrumban jako hybryda
Zespół wybiera praktyki Scrum i Kanban, które pasują do jego kontekstu.
Może na przykład zachować retrospektywy i cykliczne planowanie, ale zrezygnować z klasycznego Sprint Backlogu na rzecz ciągłego pobierania pracy.
Takie rozwiązanie nie musi już być Scrumem w rozumieniu Scrum Guide.
Scrum with Kanban
Tutaj punktem wyjścia pozostaje Scrum.
Scrum Team zachowuje:
- Sprinty,
- Sprint Goal,
- Product Backlog,
- Sprint Backlog,
- Increment,
- odpowiedzialności Product Ownera, Scrum Mastera i Developers,
- wszystkie wydarzenia Scrum.
Do tego systemu dodaje praktyki Kanban pomagające poprawić przepływ.
Scrum.org podkreśla, że w takim modelu Kanban nie zastępuje elementów Scrum, lecz je uzupełnia.
Jeżeli więc zespół już pracuje w Scrumie i jego problemem jest głównie słaby flow, podejście Scrum with Kanban jest często bardziej precyzyjnym określeniem niż całkowite przejście na Scrumban.
Scrum, Kanban i Scrumban – najważniejsze różnice
| Obszar | Scrum | Kanban | Scrum + Kanban / Scrumban |
|---|---|---|---|
| Organizacja pracy | Sprinty | Ciągły przepływ | Sprinty lub rytm Scrum połączony z zarządzaniem flow |
| Główny mechanizm kontroli pracy | Sprint Goal i Sprint Backlog | Limity WIP i system pull | Sprint Goal + kontrola WIP |
| Nowa praca | Planowana głównie w ramach Sprintu | Pobierana, gdy pojawia się capacity | Zależnie od przyjętych zasad |
| Role | Scrum Master, Product Owner, Developers | Kanban ich nie narzuca | Przy Scrum with Kanban role Scrum pozostają |
| Przepływ | Scrum go nie definiuje szczegółowo | Centralny element podejścia | Kanban pomaga analizować flow wewnątrz Scrum |
| Metryki | Scrum nie narzuca konkretnych metryk flow | Cycle time, throughput, WIP i inne | Metryki Kanban wspierają inspekcję Sprintu |
| WIP | Nie ma obowiązkowych limitów | Jawnie ograniczany | Limity WIP dodawane do workflow Scrum |
| Delivery | Increment co najmniej w każdym Sprincie, możliwe częściej | Gdy element jest gotowy | Sprint nadal daje rytm, delivery może odbywać się częściej |
Warto zwrócić uwagę na ostatni punkt.
Scrum Guide nie wymaga czekania z wydaniem produktu do końca Sprintu. Increment może zostać dostarczony przed Sprint Review, a Review nie jest bramką umożliwiającą release. Scrum pozostawia też miejsce na stosowanie dodatkowych praktyk i technik wewnątrz frameworku.
Dlatego dodanie podejścia flow nie stoi w sprzeczności ze Scrumem.
Dlaczego Scrum Team może mieć problem z przepływem?
Scrum ogranicza czas poprzez Sprint, ale sam Sprint nie ogranicza automatycznie liczby elementów rozpoczętych jednocześnie.
Załóżmy, że zespół wybiera na Sprint osiem Product Backlog Items.
Pierwszego dnia pięć osób rozpoczyna pięć różnych elementów.
Po kilku dniach sytuacja wygląda tak:
- trzy zadania czekają na code review,
- dwa na testy,
- developerzy rozpoczynają kolejne zadania,
- tester ma coraz większą kolejkę,
- pod koniec Sprintu większość pracy jest prawie skończona.
Na poziomie tablicy wszyscy są zajęci.
Na poziomie przepływu bardzo niewiele rzeczy faktycznie dociera do Done.
Problem można zapisać jako:
dużo rozpoczętej pracy → dużo oczekiwania → mało ukończonej pracy.
Kanban próbuje odwrócić tę logikę:
przestań zaczynać → zacznij kończyć.
To właśnie dlatego Scrum.org wskazuje ograniczanie WIP jako jedną z czterech podstawowych praktyk Kanban dla Scrum Teams.
Cztery praktyki Kanban, które można dodać do Scrum
Scrum.org wskazuje cztery podstawowe praktyki pomagające Scrum Teamom poprawiać przepływ:
- wizualizowanie workflow,
- ograniczanie Work in Progress,
- aktywne zarządzanie elementami będącymi w toku,
- regularną inspekcję i adaptację Definition of Workflow.
To dobry punkt startowy dla zespołu, który nie chce przebudowywać całego sposobu pracy.
1. Pokaż rzeczywisty workflow, a nie tylko To Do – Doing – Done
Wiele zespołów Scrum używa tablicy przypominającej Kanban, ale samo przesuwanie ticketów między trzema kolumnami nie oznacza jeszcze zarządzania przepływem.
Tablica powinna pokazywać rzeczywiste stany, przez które przechodzi praca.
Przykład:
Ready → Development → Code Review → Testing → Ready for Release → Done
Taki model może ujawnić, że problem nie znajduje się w developmentcie.
Jeśli po kilku dniach tablica wygląda następująco:
- Development: 2,
- Code Review: 7,
- Testing: 5,
to zespół widzi dwie kolejki, których wcześniej mogła nie pokazywać jedna ogólna kolumna In Progress.
Nie należy jednak tworzyć kolumny dla każdego drobnego działania.
Workflow powinien pokazywać stany istotne dla zarządzania przepływem, nie odwzorowywać całej instrukcji procesowej.
2. Ogranicz Work in Progress
WIP, czyli Work in Progress, oznacza liczbę elementów rozpoczętych, ale jeszcze niezakończonych. Scrum.org zalicza WIP zarówno do podstawowych metryk flow, jak i obszarów, którymi należy aktywnie zarządzać.
Załóżmy, że zespół posiada kolumnę:
Development – WIP limit: 3
Jeżeli trzy elementy są już rozwijane, czwarty nie powinien być automatycznie rozpoczynany.
Zespół najpierw sprawdza, czy może pomóc doprowadzić którąś z obecnych prac dalej.
Może to oznaczać:
- wspólne rozwiązanie problemu technicznego,
- pomoc przy code review,
- przygotowanie testów,
- usunięcie blokady,
- pairing.
WIP limit nie mówi więc:
pracujcie mniej.
Mówi:
pracujcie nad mniejszą liczbą rzeczy jednocześnie.
To duża różnica.
Limity WIP nie powinny odzwierciedlać liczby osób
Jeżeli pięciu developerów pracuje w zespole, naturalną pokusą jest ustawienie:
Development: WIP 5
Każdy ma własne zadanie i wszystkie osoby są wykorzystane.
Tyle że właśnie taki model może generować kolejki.
Jeżeli następny etap — np. review — jest w stanie obsłużyć tylko dwa elementy, development będzie stale produkował pracę szybciej niż proces potrafi ją zakończyć.
WIP limit powinien więc pomagać optymalizować cały przepływ, a nie maksymalizować wykorzystanie każdej osoby.
Czasami oznacza to, że developer pomoże w testach albo review zamiast rozpoczynać kolejną funkcję.
Z punktu widzenia lokalnego wykorzystania specjalisty może wyglądać to mniej efektywnie.
Z punktu widzenia całego systemu element trafia do Done szybciej.
3. Zmień Daily Scrum z raportowania statusu na zarządzanie przepływem
Kanban szczególnie dobrze może poprawić Daily Scrum.
Zamiast prowadzić rozmowę wokół kolejnych osób:
- co robiłem wczoraj,
- co zrobię dzisiaj,
zespół może przechodzić po przepływie.
Na przykład od prawej strony tablicy:
Co możemy dzisiaj doprowadzić do Done?
Następnie:
- które elementy są najbliżej ukończenia,
- co jest zablokowane,
- która praca starzeje się najbardziej,
- gdzie został osiągnięty limit WIP,
- kto może pomóc przesunąć pracę dalej.
To dobrze współgra z właściwym celem Daily Scrum. Scrum Guide określa go jako inspekcję postępu względem Sprint Goal i adaptowanie planu pracy, a nie status meeting dla managera.
Dodanie informacji o przepływie sprawia, że zespół podejmuje decyzje na podstawie stanu pracy, nie tylko deklaracji poszczególnych osób.
4. Obserwuj cztery metryki przepływu
Scrum nie narzuca velocity ani żadnej innej konkretnej metryki operacyjnej.
Scrum with Kanban dodaje natomiast cztery podstawowe flow metrics:
| Metryka | Co pokazuje? |
| WIP | Ile elementów jest obecnie rozpoczętych |
| Cycle Time | Ile czasu trwa przejście elementu od rozpoczęcia do zakończenia |
| Work Item Age | Jak długo aktualnie otwarty element pozostaje w toku |
| Throughput | Ile elementów zespół kończy w określonym czasie |
Scrum.org wskazuje właśnie te cztery metryki jako podstawowy zestaw dla zespołów Scrum wykorzystujących Kanban.
Nie trzeba od razu budować rozbudowanego dashboardu.
Już obserwowanie tych czterech wartości może zmienić sposób rozmowy o pracy.
Work Item Age – metryka szczególnie użyteczna podczas Sprintu
Velocity mówi przede wszystkim o przeszłości.
Work Item Age pokazuje, co dzieje się teraz.
Jeżeli element został rozpoczęty osiem dni temu i nadal znajduje się w Code Review, jest znacznie bardziej interesujący niż zadanie rozpoczęte dziś rano.
Scrum.org definiuje Work Item Age jako czas od rozpoczęcia pracy nad elementem do chwili obecnej, pod warunkiem że element nadal pozostaje w toku.
Podczas Daily Scrum można więc spojrzeć na najstarsze elementy i sprawdzić:
- dlaczego nadal nie są ukończone,
- czy coś je blokuje,
- czy są zbyt duże,
- czy wymagają pomocy innych osób.
To pozwala reagować na ryzyko przed końcem Sprintu, zamiast odkrywać je podczas Sprint Review.
Cycle Time – jak długo naprawdę trwa wykonanie elementu?
Cycle Time mierzy czas od rozpoczęcia elementu do jego ukończenia.
Przykładowo:
| Element | Cycle Time |
| A | 2 dni |
| B | 3 dni |
| C | 3 dni |
| D | 11 dni |
| E | 4 dni |
Element D powinien wzbudzić zainteresowanie.
Nie oznacza automatycznie, że ktoś pracował wolno.
Przyczyną mogło być:
- oczekiwanie na review,
- blokada techniczna,
- zależność z innym zespołem,
- niejasne wymagania,
- zbyt duży zakres,
- zmiana kontekstu.
Cycle Time staje się więc punktem startowym do analizy procesu.
Throughput zamiast obsesji na punkcie velocity
Throughput pokazuje, ile elementów pracy zostało faktycznie ukończonych w danym okresie.
Przykładowo zespół kończy:
- tydzień 1: 5 elementów,
- tydzień 2: 6,
- tydzień 3: 4,
- tydzień 4: 6.
Nie trzeba przeliczać wszystkiego na Story Points, żeby zobaczyć zachowanie procesu.
Nie oznacza to, że throughput zawsze powinien zastąpić estymację. Pokazuje jednak rzeczywisty output systemu, który można wykorzystać do prognozowania na podstawie historycznego przepływu.
Scrum.org wskazuje throughput jako liczbę ukończonych elementów w jednostce czasu.
Sprint Goal nadal jest ważniejszy niż przepływ ticketów
Dodanie Kanban do Scrum nie oznacza zamiany Sprintu w kolejkę zgłoszeń.
Scrum Guide jasno określa, że podczas Sprintu:
- nie powinny pojawiać się zmiany zagrażające Sprint Goal,
- jakość nie może spadać,
- zakres może być wyjaśniany i renegocjowany z Product Ownerem wraz ze zdobywaniem wiedzy.
To istotne przy implementacji Scrumban.
System pull nie powinien oznaczać:
skończyłem ticket, więc pobieram z Product Backlogu dowolne kolejne zadanie.
Praca nadal powinna wspierać osiągnięcie Sprint Goal.
Kanban pomaga optymalizować sposób przepływu pracy do celu, a nie zastępować cel ciągłym pobieraniem zadań.
Co zrobić z nieplanowaną pracą podczas Sprintu?
To jeden z częstszych powodów zainteresowania Scrumbanem.
Zespół produktowy planuje Sprint, ale regularnie pojawiają się:
- incydenty produkcyjne,
- pilne błędy,
- zgłoszenia klientów,
- działania operacyjne,
- problemy bezpieczeństwa.
Po kilku Sprintach połowa planu jest stale wypychana przez nowe zadania.
Nie zawsze oznacza to, że Scrum jest niewłaściwy.
Najpierw warto uwidocznić nieplanowaną pracę.
Można rozróżnić na tablicy:
- pracę związaną ze Sprint Goal,
- incydenty,
- maintenance,
- inne typy pracy.
Następnie obserwować, ile capacity faktycznie zabierają.
Jeżeli nieplanowana praca występuje sporadycznie, zespół może obsługiwać ją według jawnych zasad i renegocjować zakres Sprint Backlogu bez narażania Sprint Goal.
Jeżeli jednak każdego tygodnia napływ pracy jest bardzo duży i całkowicie nieprzewidywalny, problem może być bardziej fundamentalny.
Wtedy warto sprawdzić, czy ciągły Kanban nie pasuje do charakteru pracy lepiej niż Sprinty.
Salesforce wskazuje właśnie nieprzewidywalny, interruption-driven workload jako jedno z kryteriów przemawiających za większym wykorzystaniem przepływu Kanban.
System pull – zaczynaj pracę wtedy, gdy istnieje miejsce w procesie
W wielu zespołach praca jest pushowana.
Manager, Product Owner lub inna osoba przydziela kolejne zadanie, nawet jeśli poprzednie nadal nie zostało ukończone.
System pull działa odwrotnie.
Nowy element jest pobierany dopiero wtedy, gdy:
- poprzednia praca została przesunięta dalej,
- istnieje capacity,
- nie zostanie naruszony limit WIP.
Przykład:
Testing – WIP limit 2
Dwa elementy znajdują się już w testach.
Developer kończy trzeci.
Zamiast wrzucić go do kolejki i rozpocząć czwartą funkcję, zespół sprawdza, co zrobić, aby najpierw przesunąć obecne testy.
Właśnie wtedy Kanban zaczyna wpływać na zachowanie zespołu, a tablica przestaje być wyłącznie wizualizacją statusów.
Definition of Workflow – ustal zasady przepływu
Samo narysowanie tablicy i wpisanie limitów WIP nie wystarczy.
Zespół powinien posiadać wspólne rozumienie tego, jak działa workflow.
Przykładowo dla stanu Code Review warto określić:
- kiedy element może do niego wejść,
- co oznacza zakończenie review,
- jaki obowiązuje limit WIP,
- jak traktowany jest element zablokowany,
- kiedy praca uznawana jest za rozpoczętą,
- kiedy kończy się pomiar Cycle Time.
Scrum.org nazywa ten zestaw zasad Definition of Workflow i wskazuje jego regularną inspekcję oraz adaptację jako jedną z podstawowych praktyk Scrum with Kanban.
Nie musi to być wielostronicowa procedura.
Zasady powinny być wystarczająco jasne, aby dwie osoby patrzące na tablicę rozumiały stany w ten sam sposób.
Scrum bez kontroli przepływu – przykład
Zespół rozwija platformę SaaS i pracuje w dwutygodniowych Sprintach.
Sprint Planning kończy się wyborem ośmiu Product Backlog Items.
Po tygodniu:
- 7 elementów jest rozpoczętych,
- 4 czekają na review,
- żaden nie jest Done.
Każdy developer jest zajęty.
Velocity z poprzednich Sprintów wygląda poprawnie, ale kolejne elementy regularnie przechodzą między Sprintami.
Zespół zaczyna analizować flow.
Odkrywa, że najwięcej pracy gromadzi się w code review i testach.
Ten sam Scrum po dodaniu praktyk Kanban
Zespół nie zmienia długości Sprintu ani odpowiedzialności Scrum.
Wprowadza natomiast workflow:
Ready → Development → Review → Testing → Done
oraz pierwsze limity:
Development: 3
Review: 2
Testing: 2
Podczas Daily Scrum członkowie przestają po kolei raportować własne zadania.
Najpierw analizują najstarszą pracę i kolumny znajdujące się najbliżej Done.
Kiedy Review osiąga limit, developerzy nie rozpoczynają kolejnych Product Backlog Items. Pomagają zakończyć review.
Po kilku Sprintach zespół obserwuje:
- WIP,
- Cycle Time,
- Work Item Age,
- Throughput.
Jeżeli Cycle Time nadal jest wysoki, szuka kolejnego ograniczenia procesu.
W ten sposób Kanban nie zastąpił Scrum.
Dał zespołowi narzędzia do lepszego zarządzania tym, co dzieje się pomiędzy Sprint Planningiem a ukończeniem Incrementu.
Scrumban nie oznacza dodania większej liczby statusów w Jira
To jeden z częstszych błędów.
Zespół chce poprawić flow i rozbudowuje tablicę:
To Do → Analysis → Ready for Dev → Development → Dev Done → Ready for Review → Review → Review Done → Ready for QA → QA → QA Done → Ready for Deploy → Done
Proces wygląda dokładniej, ale sama liczba statusów nie poprawia przepływu.
Może wręcz ukryć jego problemy.
Warto wizualizować przede wszystkim te stany, które pomagają:
- zobaczyć kolejkę,
- ograniczyć WIP,
- wskazać blokadę,
- zarządzać przepływem.
Tablica jest narzędziem do podejmowania decyzji, a nie dokumentacją każdego możliwego kroku.
Popełniane błędy przy łączeniu Scrum i Kanban
Limity WIP istnieją tylko na tablicy
Kolumna ma limit 3, ale znajduje się w niej 6 elementów.
Jeżeli zespół regularnie ignoruje limit, nie zarządza WIP. Wyświetla tylko liczbę.
Przekroczenie limitu powinno być sygnałem do działania.
Każdy rozpoczyna własne zadanie
Indywidualne wykorzystanie ludzi staje się ważniejsze niż ukończenie wspólnej pracy.
Rezultatem jest dużo Doing i mało Done.
Scrumban staje się wymówką dla braku Sprint Goal
Elastyczność nie oznacza przyjmowania dowolnej pracy w dowolnym momencie.
Jeżeli zespół deklaruje, że stosuje Scrum, Sprint Goal nadal obowiązuje.
Zespół mierzy wszystko, ale niczego nie zmienia
Dashboard zawiera Cycle Time, throughput i WIP, ale retrospektywa nie prowadzi do żadnego eksperymentu.
Metryka ma wartość tylko wtedy, gdy wpływa na decyzję.
Wszystko jest oznaczane jako pilne
Jeżeli pięć elementów jednocześnie omija normalny przepływ, nie ma już procesu obsługi wyjątków.
Jest drugi, niekontrolowany workflow.
Kiedy warto dodać Kanban do Scrum?
Sygnałem nie jest sama moda na Scrumban.
Warto rozważyć praktyki flow, gdy podczas kolejnych Sprintów widzisz:
- dużo rozpoczętych, ale niedokończonych elementów,
- częste przenoszenie pracy pomiędzy Sprintami,
- kolejkę przed testami lub review,
- dużo czasu oczekiwania,
- pracę regularnie blokowaną przez zależności,
- problemy widoczne dopiero pod koniec Sprintu,
- trudności z oceną, kiedy konkretny element zostanie ukończony,
- dużo nieplanowanej pracy.
Scrum.org wskazuje, że wykorzystanie Kanban w Scrum ma właśnie pomagać w budowaniu zdrowszego, bardziej zrównoważonego przepływu i lepszej transparentności pracy.
Kiedy lepiej zostać przy Kanban bez Scrum?
Jeżeli zespół:
- niemal nieustannie reaguje na nowe zgłoszenia,
- nie jest w stanie chronić Sprint Goal,
- nie potrzebuje regularnej iteracji produktu,
- dostarcza pojedyncze elementy w sposób ciągły,
- priorytety mogą zmienić się kilka razy dziennie,
utrzymywanie Sprintów może nie dawać wystarczającej wartości.
Przykładem może być część zespołów:
- supportowych,
- operacyjnych,
- utrzymaniowych,
- incident response.
W takim przypadku warto rozważyć pełniejsze przejście na system flow zamiast sztucznie nazywać każdy dwutygodniowy okres Sprintem.
Jak zacząć poprawiać flow w Scrum bez wielkiej transformacji?
Nie zaczynałbym od ogłoszenia, że od poniedziałku zespół przechodzi na Scrumban.
Znacznie praktyczniejszy jest mały eksperyment.
Wybierz jeden obecny Sprint i zobacz rzeczywisty przepływ pracy. Ustal moment rozpoczęcia i zakończenia elementu. Rozbij jedną ogólną kolumnę In Progress na stany, które faktycznie tworzą kolejki.
Następnie wprowadź pierwszy rozsądny limit WIP w najbardziej przeciążonym miejscu.
Na Daily Scrum obserwuj przede wszystkim:
- najstarsze elementy,
- blokady,
- przekroczone limity,
- pracę najbliższą Done.
Po kilku Sprintach porównaj Cycle Time, WIP i sposób kończenia pracy.
Jeżeli elementy szybciej docierają do Done, kontynuuj eksperyment. Jeśli pojawi się nowy bottleneck, zmień Definition of Workflow lub limit i obserwuj rezultat.
To podejście dobrze wpisuje się zarówno w Kanban, jak i Scrum: nie wdrażasz docelowego procesu na podstawie teorii, tylko regularnie obserwujesz system i poprawiasz jego największe ograniczenie.
Scrumban jest najbardziej użyteczny właśnie w takim znaczeniu. Nie jako kolejna etykieta dla zespołu, lecz jako sposób wykorzystania myślenia przepływem tam, gdzie sam rytm Sprintów nie wystarcza do sprawnego kończenia pracy.
