Scrum'da Metrikler: Velocity, Burndown ve Sprint Goal Başarısı Neyi Gösterir, Neyi Göstermez?

Sürüm notu: Bu yazı Scrum Guide 2020'yi (Kasım 2020, Ken Schwaber ve Jeff Sutherland) esas alır. Yazıdaki C# kodu .NET 10 SDK (Software Development Kit) 10.0.402 ile file-based app olarak (dotnet run SprintCharts.cs) çalıştırılmıştır; gösterilen çıktı gerçek koşudandır.

Önce Tahmin Et

Bir yıl önce Bookstore'da iki ekip vardı ve ikisi de story point kullanıyordu: iade akışını yapan ekip Sprint başına ortalama 34 story point bitiriyordu, ödeme ekibi 52. Mühendislik direktörü bir sonraki çeyrek için iki hedef koydu: iade ekibi "ödeme ekibinin seviyesine yaklaşsın" ve her iki ekip de velocity'sini yüzde 10 artırsın.

Altı ay sonra iki ekibin velocity'si de gerçekten yüzde 10'dan fazla artmıştı. Ürün daha hızlı mı gelişti? Destek e-postaları azaldı mı, release sıklığı arttı mı? Tahminini yaz; cevabın büyük kısmı bu yazının sonundaki Goodhart yasasında, ama önce metriklerin ne olduğuna bakalım.

Guide Metrik Tanımlamaz

Scrum Guide 2020'de velocity kelimesi geçmez, story point geçmez, zorunlu bir chart yoktur. Metrikle ilgili tek paragraf Sprint bölümünde: burn-down, burn-up ve cumulative flow gibi pratikler ilerlemeyi forecast etmek için vardır ve faydalı olduğu kanıtlanmıştır, ama empiricism'in önemini ortadan kaldırmazlar. Karmaşık ortamda ne olacağı bilinmez; yalnızca olmuş olan, ileriye dönük karar için kullanılabilir.

Tarih de aynı yönde. 2010 Guide'ı burndown chart'ı şart koşuyordu; 2011 revizyonu bunu kaldırdı ve yalnızca Sprint'te kalan işin her gün toplanıp bilinmesini ve Sprint'in tamamlanmaya doğru gidişinin izlenmesini istedi. 2020 sürümü bunu da çıkardı. Bugün Guide'ın metrik konusundaki tavrı şu: ne ölçeceğine ekip karar verir; ama ölçüm, Increment'e ve gerçekte olana bakmanın yerine geçemez.

Bu yazı metriklerin anlamına ve kötüye kullanımına odaklanıyor. Story point'in nasıl verildiği ve velocity ile forecast'in mekaniği ilerideki Estimation ve Planning serisinin konusu; cycle time, throughput ve WIP (Work in Progress) gibi flow metric'lerinin hesaplanması ise Kanban serisinin "Flow Metric'leri: WIP, Throughput, Work Item Age ve Cycle Time" yazısında.

Burndown ve Burnup: Aynı Sprint, İki Hikâye

Bookstore ekibi Sprint 23'te board'un günlük fotoğrafını tuttu. Story point yerine item sayısı kullandılar; ekip buna bir Retrospective kararıyla geçmişti (sebebi aşağıdaki Goodhart bölümünde). Sprint 12 item'la başladı, dördüncü gün Selin ödeme sağlayıcısının bir değişikliği yüzünden üç acil item ekledi, yedinci gün bir item çıkarıldı. Aşağıdaki kod hem bu günlük veriyi hem de son altı Sprint'in özetini işliyor:

using System.Globalization;

CultureInfo.CurrentCulture = CultureInfo.GetCultureInfo("en-US");

// Sprint 23: Sprint Backlog'un günlük fotoğrafı (puan değil, item sayısı)
DaySnapshot[] days =
[
    new(0, 12, 0), new(1, 12, 0), new(2, 12, 1), new(3, 12, 2),
    new(4, 15, 3), new(5, 15, 4), new(6, 15, 5), new(7, 14, 6),
    new(8, 14, 8), new(9, 14, 10), new(10, 14, 11)
];

Console.WriteLine("day  scope  done  remaining");
foreach (DaySnapshot d in days)
{
    Console.WriteLine($"{d.Day,3}  {d.Scope,5}  {d.Done,4}  {d.Remaining,9}");
}

// son altı Sprint: numara, planlanan, Done, hedef tuttu mu, escaped defect
SprintResult[] history =
[
    new(18, 10, 9, true, 1), new(19, 11, 11, true, 0), new(20, 12, 7, false, 3),
    new(21, 12, 12, true, 0), new(22, 13, 10, false, 2), new(23, 12, 11, true, 1)
];

double goalRate = history.Count(s => s.GoalMet) / (double)history.Length;
double avgDone = history.Average(s => s.Done);
Console.WriteLine();
Console.WriteLine($"Sprints: {history.Length}, goal met: {goalRate:P0}");
Console.WriteLine($"Done per Sprint: avg {avgDone:F1}, min {history.Min(s => s.Done)}, max {history.Max(s => s.Done)}");
Console.WriteLine($"Escaped defects: {history.Sum(s => s.EscapedDefects)} total, " +
                  $"{history.Where(s => !s.GoalMet).Sum(s => s.EscapedDefects)} in missed-goal Sprints");

record DaySnapshot(int Day, int Scope, int Done)
{
    public int Remaining => Scope - Done;
}

record SprintResult(int Sprint, int Planned, int Done, bool GoalMet, int EscapedDefects);

Çıktı:

day  scope  done  remaining
  0     12     0         12
  1     12     0         12
  2     12     1         11
  3     12     2         10
  4     15     3         12
  5     15     4         11
  6     15     5         10
  7     14     6          8
  8     14     8          6
  9     14    10          4
 10     14    11          3

Sprints: 6, goal met: 67%
Done per Sprint: avg 10.0, min 7, max 12
Escaped defects: 7 total, 5 in missed-goal Sprints

Burndown chart yalnızca remaining sütununu çizer. Dördüncü günde kalan iş 12, yani Sprint'in başındaki değerle aynı. Burndown'a bakan biri "dört günde hiç ilerleme yok" sonucuna varır; oysa ekip üç item bitirmiş, aynı gün kapsam üç item büyümüş. Burnup chart ise iki çizgi çizer: toplam kapsam (scope) ve biten iş (done). İkisi ayrı göründüğü için ekibin ilerlemesi ile kapsam değişikliği birbirini gizlemez.

Bu fark yalnız görsel bir tercih değil, transparency meselesi. Kapsam değişikliği bir karardır ve Product Owner'ındır; burndown onu ekibin yavaşlığı gibi gösterir. Bookstore'da burndown'u gören satış müdürü dördüncü gün Kerem'e "ekip takıldı mı?" diye yazmıştı. Burnup'ta aynı gün iki şey görünüyor: ekip ilerliyor ve hedef çizgisi yukarı kaydı.

Velocity Neyi Gösterir, Neyi Göstermez?

Velocity, bir ekibin bir Sprint'te Done yaptığı işin kendi biriminde toplamı. Bookstore'un son altı Sprint'inde bu sayı ortalama 10 item, en düşük 7, en yüksek 12. Bu verinin en dürüst kullanımı ekibin kendi forecast'i için: Sprint Planning'de "geçmişte 7 ile 12 arasında bitirdik, bu Sprint kapasitemiz biraz düşük" demek. Ortalamadan çok aralık önemli; tek bir ortalama, bir sonraki Sprint'in 7'ye de düşebileceğini saklar.

Velocity'nin göstermediği şeyler daha uzun bir liste. Değeri göstermez: on item'ın hepsi kimsenin kullanmadığı bir ekrana gitmiş olabilir. Verimliliği göstermez: ekip item'ları küçük bölerek sayıyı artırabilir. Ekipler arası karşılaştırmaya izin vermez: story point de item de her ekibin kendi ölçeğidir; iade ekibinin 34'üyle ödeme ekibinin 52'si farklı cetvellerle ölçülmüş iki uzunluk. Direktörün "ödeme ekibinin seviyesine yaklaşsın" hedefi, aslında iade ekibinden cetvelini değiştirmesini istiyordu.

Sprint Goal Başarısı ve Escaped Defect

Bookstore'un en çok güvendiği iki sayı velocity değil. Birincisi Sprint Goal'e ulaşma oranı: altı Sprint'te dört, yani yüzde 67. Bu sayı ekibin Sprint Goal commitment'ını ne kadar güvenilir tuttuğunu gösteriyor; seçilen item'ların yüzde kaçının bittiğinden daha anlamlı, çünkü Guide'a göre commitment item listesine değil hedefe.

İkincisi escaped defect: Done sayılıp production'da bulunan hata. Altı Sprint'te toplam 7; bunların 5'i Sprint Goal'ün tutmadığı iki Sprint'ten (20 ve 22) çıkmış. Altı Sprint'lik veriyle bunu bir yasa gibi okumak yanlış olur; ama Retrospective'e götürülecek bir soru: hedef kayınca ekip son günlerde kaliteden mi kıstı? Sprint 20'nin timeline'ı bu soruya evet dedi; son iki gün integration test'ler "sonra düzeltilecek" diye skip edilmişti. Bu bulgu, bir önceki yazıdaki "skip edilmiş test yok" maddesinin Definition of Done'a girme sebebiydi.

İki sayı birlikte okunmalı. Sprint Goal başarısı tek başına hedeflenirse ekip hedefleri küçültür; escaped defect tek başına hedeflenirse bug'lar "feature request" diye yeniden etiketlenir. Birlikte bakıldığında biri diğerinin kötüye kullanımını görünür kılar.

Output Değil Outcome

Velocity, Sprint Goal başarısı ve escaped defect ekibin çıktısı hakkında. Product Goal'e ne kadar yaklaşıldığını ise ürünün kendi verisi söylüyor. Bookstore'un Product Goal'ü iade için gelen destek e-postasını haftada 120'den 20'nin altına indirmekti; Sprint 23 sonunda sayı 85'ti. Bu sayı Review'da konuşulan en önemli metrik: bir Sprint'te 12 item bitip sayı yerinden kıpırdamıyorsa, ekip hızlı ama yanlış yöne gidiyor demektir.

Scrum.org'un Evidence-Based Management (EBM) çerçevesi bu ayrımı dört alanla yapıyor: Current Value (ürünün bugün sağladığı değer), Unrealized Value (henüz yakalanmamış potansiyel değer), Time-to-Market (yeni bir şeyi ne kadar hızlı teslim edebildiğin) ve Ability to Innovate (yeni değer üretme kapasiten). EBM resmi Scrum Guide'ın parçası değil; ama "neyi ölçmeliyiz?" sorusuna output'tan outcome'a doğru bakmak için iyi bir harita. Ürün metriklerinin kendisi, yani North Star, HEART (Happiness, Engagement, Adoption, Retention, Task success) ve AARRR (Acquisition, Activation, Retention, Referral, Revenue), Product Management'a Giriş serisinin "Product Metric'leri: North Star, HEART ve AARRR" yazısında.

Goodhart Yasası

İngiliz ekonomist Charles Goodhart 1975'te para politikası üzerine yazarken, gözlemlenen bir istatistiksel düzenliliğin kontrol amacıyla üzerine baskı uygulandığında çökme eğiliminde olduğunu not etti. Antropolog Marilyn Strathern 1997'de bunu bugün bilinen genel hâline getirdi: bir ölçü hedefe dönüştüğünde iyi bir ölçü olmaktan çıkar.

Baştaki soruya dönelim. Velocity hedef olduğunda en ucuz yol puanları şişirmektir: dünün 3 puanlık item'ı bugün 5 olur. Bookstore'da bir yıl önce olan buydu: iki ekibin velocity'si altı ayda yüzde 10'dan fazla arttı, aynı dönemde release sıklığı ve iade e-postası metriği yerinde saydı. Sayı büyüdü, ürün aynı hızda kaldı; üstelik ekiplerin forecast verisi de bozuldu, çünkü geçmiş puanlarla yeni puanlar artık aynı cetvelle ölçülmüyordu. İade ekibi bu deneyimden sonra story point'i bıraktı ve Done item sayısına geçti; sayı hâlâ yalnız ekibin kendi planlaması için kullanılıyor.

Üretimde Dikkat

Metriklerin kime ait olduğu, nasıl kullanıldıklarını belirliyor. Bookstore'un kuralı: velocity ve burnup ekibin kendi planlama aracıdır ve ekip dışına raporlanmaz; ekip dışına raporlanan sayılar outcome'lar ve Sprint Goal başarısıdır. Böylece ekibin kendi forecast'i için kullandığı veri, bir performans hedefi olarak bozulmuyor.

Tek sayı yerine eğilim ve aralık: bir Sprint'lik düşüş bir şey söylemez; dört Sprint'lik eğilim söyler. Altı Sprint'lik veri bile küçük bir örneklem; Bookstore'un escaped defect bulgusu bir hipotezdi ve Retrospective'te timeline'la doğrulandı. Metriğin bir soru ürettiği, cevabı ise ekibin konuşmasının verdiği bu düzen, Guide'ın empiricism'e verdiği önceliğe uyuyor.

Ölçek büyüdükçe karşılaştırma isteği artar. Birden çok ekibin ortak bir ürün metriğine (outcome) bakması sağlıklı; aynı ekiplerin velocity'lerini yan yana koymak sağlıksız.

Sık Düşülen Tuzaklar

Velocity'yi ekipler arası karşılaştırmak ya da performans hedefi yapmak. Goodhart yasasının en bilinen yazılım örneği; sonuç puan enflasyonu ve bozulmuş forecast'ler.

Burndown'da kapsam değişikliğini kaybetmek. Kapsam büyüdüğünde düz kalan bir burndown ekibi haksız yere yavaş gösterir; kapsamın sessizce büyümesini de gizler. Burnup bu iki bilgiyi ayırır.

Yalnız output ölçmek. Velocity artarken Product Goal'e ilişkin hiçbir sayı değişmiyorsa ekip meşgul ama etkisiz olabilir.

Metriği konuşmanın yerine koymak. Bir sayının düşmesi bir sorunun varlığını gösterir, sebebini göstermez. Sebep Retrospective'te, Review'da ya da Daily Scrum'da insanlarla konuşarak bulunur.

Küçük Bir Deneme

★☆☆ Son Sprint'inizin günlük kapsam ve biten iş sayılarını çıkar ve hem burndown hem burnup olarak çiz. Kapsamın değiştiği günleri işaretle; burndown'da bu günler nasıl görünüyor?

★★☆ Yukarıdaki programa son altı Sprint'inizin verisini gir ve Done sayısının aralığını hesapla. Bir sonraki Sprint Planning'de forecast'i ortalama yerine bu aralıkla konuşmayı dene.

★★★ Ekibinizin raporladığı her metrik için "bu sayı hedef yapılırsa en ucuz nasıl iyileştirilir?" sorusunu cevapla. En ucuz yolun ürüne hiçbir faydası olmayan metrikleri işaretle ve yerine bir outcome önerisi getir.

Metrikler bir sorunun varlığını gösterir; sorunların önemli bir kısmı ise mühendislik pratiklerinde. Bir sonraki yazıda Definition of Done'ı her Sprint mümkün kılan pratiklere geçiyoruz: kısa ömürlü branch'ler, CI (Continuous Integration), yarım kalmış işi feature flag arkasında main'e merge etmek ve teknik borcu görünür kılmak.