Service Level Expectation ve Monte Carlo: "Ne Zaman Biter?" Sorusuna Olasılıkla Cevap

Sürüm notu: Bu yazı The Kanban Guide'ın 2025.5 sürümünü esas alır; Monte Carlo kodu .NET 10 ile derlenip 04. yazıdaki Bookstore board verisi üzerinde çalıştırılmıştır.

Önce Tahmin Et

30 Ekim cuma. Ürün sahibi Bookstore ekibine geliyor: gift card desteği için bir epic hazırlanmış ve ekip onu production'a ayrı ayrı çıkabilecek 30 item'a bölmüş. İki soru soruyor. Birincisi, "Bu 30 item ne zaman biter?" İkincisi, pazarlama ekibinden geliyor: "27 Kasım'daki kampanyaya kadar kaç item yetişir?"

Elinde 04. yazıdaki veri var: son 8 haftada ekip 66 item bitirdi, yani haftada ortalama 8,25 item. 30 / 8,25 ≈ 3,6 hafta; kabaca 26 Kasım. Bu tarihi ürün sahibine söyler miydin? Söylersen, gerçekleşme olasılığı sence ne kadar: %50 mi, %85 mi, %95 mi? Bir de şunu düşün: ekip bu dört haftada destek taleplerine ve bug'lara bakmayı bırakmayacak. Bu, hesabı nasıl değiştirir?

Tek Item Sorusu: SLE

"Ne zaman biter?" sorusunun iki farklı türü var ve ikisinin cevabı farklı araçlarla verilir. İlki tek bir item için sorulur: "Bu iade hatasını aldınız, ne zaman çıkar?" Bunun cevabı SLE'dir (Service Level Expectation). The Kanban Guide SLE'yi bir item'ın başlangıçtan bitişe ne kadar sürede gitmesinin beklendiğini söyleyen, bir süre ve bir olasılıktan oluşan bir tahmin olarak tarif eder ve geçmiş cycle time verisinden hesaplanmasını ister.

Hesap 04. yazıdaki percentile'dan ibaret: son 8 haftada biten 66 item'ın 85. percentile'ı 14 gün. Yani Bookstore ekibinin SLE'si "item'ların %85'i başladıktan sonra 14 gün içinde biter." Bu cümle müşteriye "elimizden geleni yapacağız"dan çok daha fazlasını söyler, ama dikkat: başlangıç noktası item'ın Ready'den çekildiği an. Item henüz Ready'de bekliyorsa, onun önündeki kuyruk da hesaba girmeli; SLE taahhüt anından sonrasını anlatır.

SLE ile Work Item Age birlikte çalışır. Bir item 10 günlük olduysa ve SLE 14 günse, item'ın bitmesine kalan süre için SLE'yi değil, "bu yaştaki item'lar genellikle ne zaman bitiyor" sorusunu sormak gerekir; ama pratikte ekibin yapacağı şey basit: SLE'ye yaklaşan item'ı Daily'de gündemin başına koymak.

Çok Item Sorusu: Ne Zaman ve Ne Kadar

İkinci tür soru birden fazla item içindir ve iki biçimde gelir. "30 item ne zaman biter?" sorusunda kapsam sabittir, tarih bilinmez. "27 Kasım'a kadar kaç item?" sorusunda tarih sabittir, kapsam bilinmez. İkisi de aynı veriyle, geçmiş throughput ile cevaplanır.

Baştaki hesap, 30 / ortalama throughput, bu sorulara tek bir sayı verir. Sorun şu ki throughput sabit değil; 04. yazıda haftalık throughput'un 5 ile 11 arasında oynadığını gördük. Ortalama ile yapılan tahmin, aslında "her şey ortalama giderse" tahminidir ve bu, olasılık olarak kabaca yazı turadır. Bize lazım olan tek bir tarih değil, tarihlerin dağılımı.

Monte Carlo simülasyonu bunu yapar. Fikir şöyle: geçmişteki her günün throughput'u, gelecekteki bir günün olası bir throughput'udur. Geleceği bir kez değil binlerce kez simüle edersin; her simülasyonda her gün için geçmişten rastgele bir gün seçer ve o günün throughput'unu kullanırsın. 10.000 farklı olası gelecek elde ettiğinde, "30 item kaç günde biter" sorusunun 10.000 cevabı olur; bunların dağılımı sana olasılığı verir.

Bu yöntemin tek varsayımı şu: yakın gelecek, örneklem aldığın geçmişe benzeyecek. Varsayımın ne zaman bozulduğunu aşağıda konuşacağız.

Kod: 10.000 Olası Gelecek

04. yazıdaki WorkItem, BoardCsv ve Stats tiplerini aynen kullanıyoruz; yeni proje FlowForecast, tek dosya:

using System.Globalization;
using Bookstore.Flow;

CultureInfo.CurrentCulture = CultureInfo.InvariantCulture;

DateOnly today = new(2026, 10, 30);
List<WorkItem> items = BoardCsv.Load("board-history.csv");

// Örneklem: son 8 haftanın (56 takvim günü) her günü için Done'a giren item sayısı, 0'lar dahil
DateOnly from = today.AddDays(-55);
int[] daily = [.. Enumerable.Range(0, 56).Select(d => items.Count(i => i.Finished == from.AddDays(d)))];
Console.WriteLine($"Sample: {daily.Length} days, {daily.Sum()} items, zero days = {daily.Count(x => x == 0)}");

// SLE: aynı pencerede biten item'ların cycle time'ı
List<int> ct = [.. items.Where(i => i.Finished >= from).Select(i => i.CycleTimeDays!.Value).Order()];
Console.WriteLine($"SLE: 85% of items finish within {Stats.Percentile(ct, 85)} days (n = {ct.Count})");

const int Runs = 10_000;
Random rng = new(2026);

// Soru 1: 27 Kasım akşamına kadar (28 gün) kaç item biter?
DateOnly deadline = new(2026, 11, 27);
int horizon = deadline.DayNumber - today.DayNumber;
List<int> howMany = [.. Enumerable.Range(0, Runs)
    .Select(_ => Enumerable.Range(0, horizon).Sum(_ => daily[rng.Next(daily.Length)]))
    .Order()];

Console.WriteLine();
Console.WriteLine($"How many items by {deadline:yyyy-MM-dd} ({horizon} days)?");
foreach (int confidence in new[] { 50, 70, 85, 95 })
    Console.WriteLine($"  {confidence}% confidence: at least {Stats.Percentile(howMany, 100 - confidence)} items");

// Soru 2: Gift card epic'inin 30 item'ı ne zaman biter?
const int Backlog = 30;
List<int> daysNeeded = [.. Enumerable.Range(0, Runs).Select(_ => DaysUntilDone(Backlog)).Order()];

Console.WriteLine();
Console.WriteLine($"When will {Backlog} items be done (starting {today.AddDays(1):yyyy-MM-dd})?");
foreach (int confidence in new[] { 50, 70, 85, 95 })
{
    int days = Stats.Percentile(daysNeeded, confidence);
    Console.WriteLine($"  {confidence}% confidence: on or before {today.AddDays(days):yyyy-MM-dd} ({days} days)");
}

// Dağılımın kaba histogramı (haftalık kova)
Console.WriteLine();
foreach (IGrouping<int, int> week in daysNeeded.GroupBy(d => (d - 1) / 7))
    Console.WriteLine($"  week {week.Key + 1,2}: {week.Count() * 100.0 / Runs,5:F1}% {new string('#', week.Count() * 100 / Runs)}");

int DaysUntilDone(int remaining)
{
    int days = 0;
    while (remaining > 0)
    {
        remaining -= daily[rng.Next(daily.Length)];
        days++;
    }
    return days;
}

Örneklem, son 56 takvim gününün her biri için Done'a giren item sayısı. Hafta sonları ve deploy olmayan günler sıfır olarak listede duruyor; bu bilinçli. Simülasyon takvim günü ilerliyor, yani bir cumartesi örneklemden bir pazartesi de çekebilir, bir sıfır gün de. Uzun bir ufukta bu ortalamaya yakınsar.

Random'a sabit bir seed (2026) veriyoruz ki çıktı tekrarlanabilir olsun; gerçek kullanımda seed'siz çalıştırmak da olur, 10.000 çalıştırmada sonuç bir iki gün oynar. Gerçek çıktı:

Sample: 56 days, 66 items, zero days = 40
SLE: 85% of items finish within 14 days (n = 66)

How many items by 2026-11-27 (28 days)?
  50% confidence: at least 32 items
  70% confidence: at least 27 items
  85% confidence: at least 22 items
  95% confidence: at least 16 items

When will 30 items be done (starting 2026-10-31)?
  50% confidence: on or before 2026-11-25 (26 days)
  70% confidence: on or before 2026-11-30 (31 days)
  85% confidence: on or before 2026-12-06 (37 days)
  95% confidence: on or before 2026-12-13 (44 days)

  week  1:   0.1% 
  week  2:   5.2% #####
  week  3:  24.1% ########################
  week  4:  31.2% ###############################
  week  5:  22.2% ######################
  week  6:  11.3% ###########
  week  7:   4.2% ####
  week  8:   1.2% #
  week  9:   0.4% 
  week 10:   0.2% 
  week 11:   0.1% 
  week 12:   0.0% 

Çıktıyı Okumak

Örneklemde 56 günün 40'ı sıfır: hafta sonları ve ekibin deploy etmediği günler. Kalan 16 günde 66 item bitmiş. SLE satırı 04. yazıdaki son 8 haftanın p85'iyle aynı: 14 gün.

"27 Kasım'a kadar kaç item?" sorusunun cevabını aşağıdan yukarıya okuruz: simülasyonların %85'inde en az 22 item bitiyor, %50'sinde en az 32. Bu soruda yüksek güven, daha az item demektir. Pazarlama ekibine söylenecek cümle "27 Kasım'a kadar %85 olasılıkla en az 22 item bitecek"tir. Eğer kampanya için gereken gift card item'ları 22'nin içine sığıyorsa rahat; 30 gerekiyorsa, şansın yazı turadan biraz fazla.

"30 item ne zaman biter?" sorusunda ise yüksek güven, daha geç tarih demektir. %50 olasılıkla 25 Kasım veya öncesi, %85 olasılıkla 6 Aralık veya öncesi, %95 olasılıkla 13 Aralık veya öncesi. Baştaki ortalama hesabın verdiği 26 Kasım, bu dağılımın tam ortasına düşüyor: yani "ortalama" tahmin, %50 civarında bir olasılık taşıyor. Ürün sahibine 26 Kasım'ı söyleseydin, kabaca iki projeden birinde sözünü tutamayacaktın.

Haftalık histogram dağılımın şeklini gösteriyor: en olası sonuç dördüncü hafta (%31), ama altıncı hafta ve sonrası toplamda %17. Sağa doğru uzanan bu kuyruk, "her şey iyi giderse" planlarının neden hep geç kaldığını açıklıyor.

Stakeholder'a Nasıl Söylenir

Tahmini tek tarih olarak değil, olasılıkla birlikte ver: "Bu 30 item'ın %85 olasılıkla 6 Aralık'a kadar biteceğini öngörüyoruz; %50 olasılıkla 25 Kasım." Ürün sahibi hangi riski alabileceğine kendisi karar verir. Bir sözleşme tarihine bağlanacaksa %95'i, iç planlamada %70–85'i kullanmak yaygın bir tercih.

Bu yaklaşım story point tabanlı tahminden farklı bir yerden gelir. Scrum serisinin metrikler yazısında velocity'nin neyi gösterip neyi göstermediğini konuştuk; ilerideki Estimation ve Planning serisi de story point, planning poker ve release planlamayı anlatacak. Throughput tabanlı Monte Carlo'nun farkı, item'ları tek tek tahmin etmeyi gerektirmemesi: yalnız item'ları sayarsın. Bunun çalışması için item'ların aşağı yukarı aynı türde olması yeterli; birebir aynı boyutta olmaları gerekmez, çünkü boyut farkı geçmiş throughput'un içinde zaten var.

Tahmini her hafta yenile. Her pazartesi yeni bir hafta veriye girer, bir hafta düşer; tahmin daralır ya da kayar. Monte Carlo bir kerelik bir söz değil, her hafta güncellenen bir hava durumu raporudur. Kayan tahmin bir başarısızlık değil, erken uyarıdır: 85. percentile tarihi iki hafta üst üste ileri kayıyorsa, ürün sahibinin kapsamı konuşması için hâlâ vakti var.

Sınırlar: Monte Carlo Ne Zaman Yanılır

Sistem değiştiyse geçmiş geleceği anlatmaz. Bookstore ekibi Eylül'de WIP (Work in Progress) limit'lerini değiştirdi; 8 haftalık pencere bu yüzden 5 Eylül'den başlıyor. Mayıs verisiyle çalışsaydık tahmin gereksiz yere kötümser çıkacaktı. Ekipten iki kişi ayrılırsa, ya da Aralık'ta yarı ekip izne çıkarsa, son 8 haftanın throughput'u gelecek 6 haftayı anlatmaz; bunu ya pencereyi ayarlayarak ya da tahmine elle bir not düşerek hesaba katmalısın.

Az veri belirsizliği büyütür. 66 item ile çalışmak rahat; 15 item'lık bir geçmişle percentile'lar ve histogram çok oynar. Yeni bir ekipte ilk birkaç hafta tahmini geniş aralıkla ver.

Throughput epic'e özel değil. Baştaki ikinci soruya dönelim: örneklemdeki 66 item'ın hepsi gift card item'ı değildi; bug'lar, destek talepleri, başka feature'lar da vardı. Ekip bu dört haftada da destek işine bakmaya devam edecekse, 30 gift card item'ı ekibin toplam throughput'unun yalnız bir kısmını alır. İki yol var: ya backlog'u "30 gift card item'ı + bu dönemde gelmesi beklenen destek ve bug item'ları" diye büyütürsün (geçmişte haftada kaç destek item'ı geldiğine bakarak), ya da örneklemi yalnız feature türündeki throughput'la kurarsın. İkisini de yapmazsan tahmin iyimser çıkar.

Epic'ler büyür. 30 item'a bölünen bir epic, iş ilerledikçe 36 item'a çıkabilir; yeni öğrenilenler yeni item'lar doğurur. Bunu da geçmiş epic'lerde item sayısının ne kadar arttığına bakarak tahmine ekleyebilirsin.

Günleri bağımsız örneklemek deploy ritmini yok sayar. Bookstore haftada iki kez deploy ediyor, yani gerçek throughput salı ve perşembe toplanıyor. Bizim simülasyonumuz günleri bağımsız seçtiği için bir simülasyonda üst üste beş "deploy günü" çekebilir. Uzun ufukta bu etki küçülür, ama kısa ufuklu tahminlerde (bir iki hafta) haftalık throughput'tan örneklem almak daha gerçekçi olabilir.

Üretimde Dikkat

Seed'i ve pencereyi raporla. "Tahmin, 5 Eylül–30 Ekim throughput'u ile 10.000 çalıştırma" gibi tek bir satır, tahmini tekrarlanabilir ve tartışılabilir kılar. Seed'siz çalıştırıyorsan iki çalıştırmanın sonuçlarının bir iki gün farklı olabileceğini söyle; insanlar aksi hâlde farkı hata sanar.

Çalıştırma sayısını abartma. 10.000 çalıştırma bu veride bir saniyenin altında bitiyor ve percentile'lar artık kıpırdamıyor. 1 milyon çalıştırma tahmini daha doğru yapmaz; belirsizlik simülasyondan değil, geçmişin geleceği ne kadar iyi anlattığından gelir.

Tahmini otomatikleştir. 04. yazıdaki haftalık metric job'una bu hesabı eklemek, ürün sahibine her pazartesi güncel bir "%85 tarihi" göndermek demek. Tahmin bir toplantının çıktısı olmaktan çıkar, sürekli görünen bir sinyal olur.

Sık Düşülen Tuzaklar

Ortalamayla tahmin etmek en yaygın tuzak. "Haftada 8 item yapıyoruz, 30 item 4 haftada biter" cümlesi %50'lik bir tahmindir ama %100'lük bir söz gibi duyulur.

İkinci tuzak percentile'ı yanlış yönden okumak. "Kaç item?" sorusunda %85 güven, dağılımın 15. percentile'ıdır; "ne zaman?" sorusunda %85 güven, dağılımın 85. percentile'ıdır. Kodda Stats.Percentile(howMany, 100 - confidence) satırı bu yüzden var; bu satırı yanlış yazmak, en iyimser senaryoyu %85 güvenli diye raporlamak demektir.

Üçüncüsü sıfır günleri örneklemden çıkarmak. "Sıfır gün anlamsız, hafta sonu zaten çalışmıyoruz" diye sıfırları atarsan ve simülasyonu yine takvim günüyle ilerletirsen, her takvim gününe çalışılan bir günün throughput'unu vermiş olursun. Bu veride deploy olmayan günler de sıfır olduğu için hata daha da büyür: sıfır olmayan 16 günün ortalaması günde 4 item, gerçek takvim ortalaması ise 1,2; tahmin birkaç kat iyimser çıkar. Sıfırları tut.

Dördüncüsü tahmini bir hedefe çevirmek. "%85 tarihi 6 Aralık" bir öngörüdür. Yönetici bunu "6 Aralık deadline'ı" diye ekibe geri gönderirse, ekip WIP'i artırarak ya da Done'ı esneterek tarihe yetişmeye çalışır ve bir sonraki tahminin dayandığı veriyi bozar.

Küçük Bir Deneme

★☆☆ Simülasyonu 4, 8 ve 16 haftalık pencerelerle çalıştır. "30 item" sorusunun %85 tarihi nasıl değişiyor? 16 haftalık pencere Eylül öncesini de içeriyor; sonuç az değişse bile bunu yapmak neden riskli?

★★☆ Örneklemi günlük yerine haftalık throughput'tan kur (son 8 haftanın 8 değeri) ve simülasyonu hafta hafta ilerlet. %50 ve %85 tarihleri günlük örneklemle ne kadar farklı?

★★★ Backlog'u gerçekçi hâle getir: son 8 haftada haftada ortalama kaç Support ve Bug item'ı bittiğini hesapla ve her simülasyonda, simüle edilen her hafta için bu kadar item'ı backlog'a ekle. 30 gift card item'ının %85 tarihi kaç gün kayıyor?

Ölçtük ve tahmin ettik. Bir sonraki yazıda bu sayıları her gün kullanmaya geçiyoruz: Daily toplantısını board'un sağından sola yönetmeyi, blocked item'ları, expedite policy'sinin bedelini ve Bookstore ekibinin Code Review bottleneck'ini verisiyle nasıl çözdüğünü konuşacağız.