Scrumban ve Kanban Guide for Scrum Teams: Scrum'a Flow Eklemek

Sürüm notu: Bu yazı The Kanban Guide 2025.5'i, Scrum.org'un Kanban Guide for Scrum Teams rehberini (2021 güncellemesi) ve Scrum Guide 2020'yi esas alır.

Önce Tahmin Et

Bookstore'da destek ekibinin yanında ikinci bir ekip var: katalog ve arama tarafında ürün geliştiren, iki haftalık Sprint'lerle çalışan bir Scrum Team. Son dört Sprint'in retro'larında aynı şikâyet çıkıyor: Sprint sonunda yarım kalmış üç dört item bir sonraki Sprint'e taşınıyor, Sprint Review'da gösterilecek bitmiş iş azalıyor. Ekipten biri öneriyor: "Destek ekibi Kanban'a geçti ve memnun. Biz de Scrumban yapalım: Sprint'leri bırakalım, board'a WIP (Work in Progress) limit koyalım, iş geldikçe çekelim."

Bu öneri ekibin sorununu çözer mi? Sprint'i bırakınca ekip neyi kaybeder? Bir de şunu düşün: Sprint sonunda yarım kalan işin sebebi Sprint'in kendisi mi, yoksa Sprint'in içinde aynı anda kaç işe başlandığı mı?

Ladas'ın Scrumban'ı: Bir Geçiş Yolu

"Scrumban" kelimesi Corey Ladas'ın 2007–2008'de yazdığı essay'lerden geliyor; bu yazılar 2008'de "Scrumban: Essays on Kanban Systems for Lean Software Development" kitabında toplandı. Ladas Scrumban'ı başlangıçta bir Scrum ekibinin Kanban'ın pull sistemine doğru adım adım ilerlemesi için bir yol olarak tarif etti: önce board'u görünür kıl, sonra WIP limit'leri ekle, en sonunda sabit uzunluklu iterasyonları ve toplu planlamayı, kuyruk belirli bir seviyenin altına düştüğünde tetiklenen planlamayla değiştir. Yani Ladas'ın Scrumban'ı bir varış noktası değil, Scrum'dan continuous flow'a giden bir köprüydü.

Bugün "Scrumban" kelimesi çok daha gevşek kullanılıyor. Bir ekip "Scrumban yapıyoruz" dediğinde çoğu zaman Scrum'ın bazı parçalarını (Daily, retro, belki Sprint Review) tutup bazılarını (Sprint Goal, Sprint Planning) bıraktığını ve board'a bir şeyler eklediğini kastediyor. Bunun resmi bir tarifi yok; Scrum Guide da The Kanban Guide da Scrumban'ı tanımlamaz. Bu yüzden "Scrumban" dediğinde ne kastettiğini her seferinde açıkça yazmak gerekir.

Kanban Guide for Scrum Teams

Scrum.org bu karışıklığa daha yapılandırılmış bir cevap verdi: Kanban Guide for Scrum Teams. Daniel Vacanti ve Yuval Yeret'in Scrum.org topluluğuyla birlikte geliştirdiği rehber, Ocak 2021'de Scrum Guide 2020'ye uyacak şekilde güncellendi. Rehberin ilk ve en önemli cümlesi, Scrum Guide'ın hiçbir parçasını değiştirmediği ya da yok saymadığıdır. Kanban burada Scrum'ın yerine geçmez; Scrum'ın üzerine flow bakışı ekler.

Rehber Scrum Team'den dört pratik ister: workflow'u görselleştirmek, WIP'i sınırlamak, devam eden item'ları aktif olarak yönetmek ve Definition of Workflow'u inspect edip adapt etmek. Ölçmek için de bu serinin dört metric'ini kullanır: WIP, Cycle Time, Work Item Age ve Throughput. Definition of Workflow (DoW) Scrum Team'e aittir, dışarıdan dikte edilmez ve tek bir Sprint'le sınırlı değildir; item'lar Sprint sınırını aşabilir, DoW da aşar. SLE (Service Level Expectation) rehberde de geçmiş cycle time'dan hesaplanan bir süre ve olasılık olarak tarif edilir; veri yoksa ekip bir tahminle başlar.

Rehberin bilinçli olarak dışarıda bıraktığı şeyler de var. Yeret, cost of delay ve flow efficiency gibi kavramları bu minimum sete almadıklarını, çünkü bunların bir Scrum Team'in flow'u iyileştirmesi için şart olmadığını yazar. Rehber The Kanban Guide gibi kısa ve minimal.

Event'ler Üzerinde Flow

Rehberin en pratik bölümü, flow'un her Scrum event'ine nasıl eklendiğini anlatan bölüm:

Sprint'in kendisi değişmez. Sprint, DoW'u ve flow metric'lerini inspect ve adapt etmek için bir feedback döngüsü olarak kalır ve Scrum Team her Sprint'te en az bir kullanılabilir Increment üretmeye devam eder.

Sprint Planning'de geçmiş throughput, Sprint Backlog'a kaç item alınabileceğine dair kapasite bilgisidir. Bu, velocity'nin yerini doğrudan alabilir: story point toplamı yerine son Sprint'lerde biten item sayısına bakılır. SLE de burada işe yarar: SLE'den büyük görünen bir item Sprint'e alınmadan önce bölünür.

Daily Scrum board'un etrafında yapılır ve flow'un aksadığı yere odaklanır: blocked ya da yavaş ilerleyen item'lar, Work Item Age, SLE'yi aşma riski olan item'lar ve WIP limit ihlalleri. Bu, 06. yazıda anlattığımız sağdan sola, en yaşlıdan başlayan toplantının Scrum'daki karşılığı.

Sprint Review'da flow metric'leri Product Goal'a doğru ilerleme konuşmasını besler. Throughput, 05. yazıdaki Monte Carlo ile birlikte "bu gidişle Product Goal'a ne zaman ulaşırız?" sorusuna olasılıklı bir cevap verir.

Sprint Retrospective'de ekip flow metric'lerini ve analizleri inceler ve bir sonraki Sprint için DoW'u uyarlar. Rehber CFD'nin (Cumulative Flow Diagram) bu noktada faydalı olduğunu söyler; 04. yazıdaki cycle time scatterplot da buraya uyar.

Bookstore Katalog Ekibi: Scrum'a Flow Eklemek

Katalog ekibi Sprint'leri bırakmak yerine rehberdeki yolu denedi. İlk Sprint'te board'larına 02. yazıdaki gibi bir DoW yazdılar: started noktası item'ın Sprint Backlog'dan In Dev'e çekildiği an, finished noktası production deploy'u. In Dev'e 4, Code Review'a 2 WIP limit'i koydular.

İlk retro'da sorunun Sprint değil, Sprint'in ilk iki gününde ekibin dokuz item'ın hepsine birden başlaması olduğu ortaya çıktı. Her geliştirici iki üç item açıyordu, hepsi Sprint'in son günlerinde aynı anda Code Review'a ve test'e yığılıyordu. Sprint sonunda yarım kalan item'lar, Sprint'in içindeki yüksek WIP'in doğrudan sonucuydu. WIP limit'i bunu çözdü: item'lar Sprint boyunca tek tek bitmeye başladı ve Sprint sonundaki "son gün telaşı" azaldı.

Sprint Planning'de story point yerine son üç Sprint'in throughput'una bakmaya başladılar. Daily Scrum'da her sabah aging chart'a bakıyorlar. Sprint Goal ise olduğu gibi kaldı; Kanban ona dokunmadı. Scrum Guide 2020 velocity'den hiç bahsetmez ve Sprint Backlog'u neyle tahmin edeceğini ekibe bırakır; dolayısıyla story point'ten throughput'a geçmek Scrum'dan ayrılmak değil, Scrum'ın bıraktığı bir seçimi farklı yapmaktır. Story point'li yaklaşımın ayrıntısı ilerideki Estimation ve Planning serisinin konusu.

Karar: Scrum, Kanban ya da İkisi Birlikte

Hangi ekip için hangisi? Kesin bir kural yok, ama işin doğası iyi bir ipucu verir:

Bookstore'da destek ekibi Kanban'da, katalog ekibi Scrum + flow ile çalışıyor ve bu iki seçim birbiriyle çelişmiyor. İki ekip aynı dört metric'i aynı şekilde hesapladığı için yöneticiler iki ekibin flow'unu aynı dille konuşabiliyor; ama iki ekibin throughput'unu toplamıyorlar, çünkü item tanımları farklı.

Üretimde Dikkat

Velocity ile throughput'u aynı grafikte karıştırma. Geçiş döneminde iki sayıyı birlikte izlemek mantıklı, ama birini diğerine çevirmeye çalışma ("1 item = 5 point") ve Sprint Planning'de hangisine baktığını açıkça söyle.

Sprint sınırında cycle time'ı sıfırlama. Bir item Sprint sonunda bitmediyse ve bir sonraki Sprint'e taşındıysa, cycle time'ı item'ın In Dev'e ilk girdiği günden saymaya devam eder. Sprint'e "yeniden planlandı" diye başlangıç tarihini güncellemek, en uzun süren item'ları ölçümden siler.

DoW'u Scrum Team'in elinde tut. Rehber DoW'un dışarıdan dikte edilmemesi gerektiğini açıkça söyler. Bir PMO'nun (Project Management Office) bütün ekiplere aynı kolonları ve aynı WIP limit'lerini dayatması, her ekibin farklı işini aynı kalıba sokar.

Sık Düşülen Tuzaklar

En büyük tuzak "Scrumban" adıyla yapıyı bırakmak: Sprint'i bırakıp WIP limit'i de koymamak, Sprint Goal'u bırakıp yerine bir şey koymamak, retro'yu bırakıp iyileştirmeyi hiç yapmamak. Sonuç Scrum da Kanban da değildir; baştaki katalog ekibinin önerisi tam olarak bu riski taşıyordu. Bir şeyi bırakıyorsan, onun sağladığı şeyi (ritim, odak, iyileştirme) neyin sağlayacağını yaz.

İkinci tuzak Sprint'i flow'un düşmanı saymak. Sprint bir planlama ve inspect/adapt ritmidir; item'ların Sprint'in sonunda toplu bitmesi Sprint'in değil, Sprint içindeki WIP'in sonucudur. Katalog ekibi Sprint'leri bırakmadan, yalnız WIP'i sınırlayarak bu sorunu çözdü.

Üçüncüsü Kanban'ı Scrum'ın içinde bir "board aracı" olarak görmek. Kanban Guide for Scrum Teams board'u değil, DoW'u, WIP kontrolünü ve aktif yönetimi ister; board'u Jira'da Kanban görünümüne çevirmek tek başına hiçbir şey değiştirmez. Bu, serinin ilk yazısındaki uyarının Scrum'daki karşılığı.

Dördüncüsü Sprint Goal'u throughput hedefiyle değiştirmek. "Bu Sprint 15 item bitireceğiz" bir Sprint Goal değildir; Sprint Goal neden çalıştığını söyler, throughput ne kadar bitirdiğini. İkisi birlikte kullanılır, biri diğerinin yerine geçmez.

Küçük Bir Deneme

★☆☆ Ekibinin son üç Sprint'inin her biri için Sprint sonunda kaç item'ın yarım kaldığını ve Sprint'in ilk iki gününde kaç item'a başlandığını say. İki sayı arasında bir ilişki görüyor musun?

★★☆ Bir sonraki Sprint Planning'de story point toplamının yanına son üç Sprint'in throughput'unu da koy ve iki yöntemin önerdiği Sprint Backlog büyüklüğünü karşılaştır. Sprint sonunda hangisi gerçeğe daha yakın çıktı?

★★★ Ekibin için bu yazıdaki karar tablosunu doldur: işinizin doğası hangi satıra benziyor? Seçtiğin modeli, ekibin bıraktığı her Scrum ya da Kanban parçasının yerine neyin geçtiğini gösteren tek sayfalık bir notla gerekçelendir.

Kanban serisi burada bitiyor: board'dan Definition of Workflow'a, WIP'ten Little's Law'a, dört flow metric'inden Monte Carlo tahminine ve günlük aktif yönetime kadar geldik. Flow, işi doğru şekilde akıtmayı anlatır; neyin akması gerektiğini söylemez. O soru, yani doğru şeyi inşa etmek, Product Management'a Giriş serisinin konusu.