Scrum ekipleri için akış metrikleri: döngü süresi, çıktı miktarı ve gerçekte ölçülmesi gerekenler

Agile team gathered around a board with flowing streams of work items moving through columns, illustrated in a modern flat style with bright colors Ekibiniz hızı (velocity) takip ediyor. Sprint planlamasında bundan bahsediyorsunuz, belki retrospektiflerde referans veriyorsunuz. Ancak bir paydaş "bu ne zaman bitecek?" diye sorduğunda hala tahmin yürütmek zorunda kalıyorsunuz. Hız size ne kadar tahmin ettiğiniz işi tamamladığınızı söyler, işlerin gerçekte ne kadar sürdüğünü veya işin nerede takıldığını değil. Akış metrikleri bu boşluğu doldurur. Tahminler yerine gerçek verileri kullanarak sürecinizde gerçekte ne olduğunu ölçerler. Ve bunları kullanmak için Scrum'dan vazgeçmenize veya "Kanban'a geçmenize" gerek yok.

Önemli olan dört metrik

Scrum Ekipleri İçin Kanban Rehberi (Scrum.org tarafından yayınlanmıştır) dört akış metriği tanımlar. Her birinin size ne söylediği ve neden takip etmeye değer olduğu aşağıda açıklanmıştır.

Devam eden iş (WIP)

Ekibinizin başlattığı ancak tamamlamadığı öğelerin sayısı. Formül yok, sadece bir sayı. WIP önemlidir çünkü basit bir gerçeği ortaya koyar: ne kadar çok şeyle uğraşırsanız, her şey o kadar uzun sürer. Bağlam değiştirme, el değiştirme ve bekleme süresi, daha yüksek WIP ile artar. Çoğu ekip, gerçek WIP'lerini ilk saydıklarında şaşırır.

Döngü süresi (Cycle time)

İşin başladığı andan tamamlandığı ana kadar geçen takvim süresi. Çaba saati değil, duvar saati zamanı. Döngü süresi gecikmeli bir göstergedir. Bunu yalnızca bir öğe bittikten sonra bilirsiniz. Ancak yeterli veri noktası toplayın (30+ hedefleyin) ve "öğelerimizin %85'i 10 gün veya daha kısa sürede bitiyor" gibi şeyler söyleyebilirsiniz. Bu bir Service Level Expectation (SLE)'dir ve hıza dayalı bir tahminden çok daha kullanışlıdır.

Çıktı miktarı (Throughput)

Ekibinizin birim zaman başına bitirdiği öğe sayısı, genellikle sprint başına veya hafta başına. Çıktı miktarı, boyuttan bağımsız olarak tamamlanan öğelerin sayısıdır. 3 puanlık bir hikaye ile 8 puanlık bir hikaye her biri bir olarak sayılır. Bu bir sınırlama gibi görünüyor, ancak aslında bir güçtür: puanlarınızın "doğru" olup olmadığı konusundaki tüm tartışmaları es geçer ve gerçekte neyi teslim ettiğinizi ölçer.

İş öğesi yaşı (Work item age)

Devam eden bir öğenin başlatılmasından bu yana geçen süre. Bunu henüz tamamlanmamış şeyler için döngü süresi olarak düşünün. Bu, günlük olarak kontrol etmeniz gereken tek metriktir. Bir öğenin yaşı tipik döngü sürenize yaklaşıyorsa ve hala tamamlanmaktan uzaksa, bu erken bir uyarı işaretidir. Öğe bittikten sonra yaşı döngü süresine dönüşür. O zamana kadar, en iyi öncü göstergenizdir.

Illustrated dashboard showing four colorful metric cards for WIP, cycle time, throughput, and work item age with small chart icons on each

Bu metrikler nasıl bağlantılıdır

Little Yasası ilk üçünü bir araya getirir: Ortalama WIP = Ortalama Çıktı × Ortalama Döngü Süresi Bu pratikte önemlidir. Başka bir şeyi değiştirmeden WIP'yi azaltırsanız, döngü süresi düşer. Ekibinizin daha hızlı çalışmasına gerek yoktur. Aynı anda daha az şey üzerinde çalışmaları gerekir.

Eğer... istiyorsanız	O zaman...
Döngü süresini azaltmak	WIP'nizi düşürün
Çıktı miktarını artırmak	Yeni işe başlamadan önce mevcut işi bitirin
Teslimat tarihlerini tahmin etmek	Döngü süresi yüzdeliklerini kullanın (SLE'ler)
Sorunları erken fark etmek	İş öğesi yaşını günlük izleyin

Sürecinizi kaptan aşağı değiştirmeden başlamak

Yeni araçlara veya süreç iyileştirmesine ihtiyacınız yok. İşte pratik bir yol.

Öğe başına üç tarihi takip edin

Her ürün biriktirme listesi öğesi için, ne zaman oluşturulduğunu, işin ne zaman başladığını ve ne zaman tamamlandığını kaydedin. Jira ve Azure DevOps gibi çoğu araç bunu zaten yakalar. Sadece buna dikkat etmeye başlamanız gerekir.

İş akışınızı açıkça tanımlayın

Ekibiniz için "başladı" ve "tamamlandı"nın ne anlama geldiğini yazın. Panonuzdaki sütunlar nelerdir? Öğeleri aralarında taşımak için kurallar nelerdir? Bu sizin İş Akışı Tanımınızdır ve tutarlı ölçüm için temeldir.

Birkaç sprint için veri toplayın

Henüz hiçbir şeyi analiz etmeye çalışmayın. Sadece verinin birikmesine izin verin. Anlamlı desenler için en az 30 tamamlanmış öğeye ihtiyacınız var, çoğu ekip bunu 3-4 sprintte yakalar.

İlk döngü süresi dağılım grafiğinizi oluşturun

Her tamamlanmış öğeyi x ekseninde bitiş tarihi ve y ekseninde döngü süresi ile çizin. 50., 85. ve 95. yüzdeliklerde yatay çizgiler çizin. 85. yüzdeliğiniz bir SLE için sağlam bir başlangıç noktasıdır.

Bunu Scrum etkinliklerinize getirin

Sprint planlamasında hız yerine (veya yanında) çıktı geçmişini kullanın. Günlük scrum'larda iş öğesi yaşını kontrol edin. Retrospektiflerde döngü süresi trendlerini gözden geçirin. Sprint incelemelerinde SLE performansını sunun.

Akış metriklerinin her Scrum etkinliğinde nereye uyduğu

Bu metrikler, zaten yürüttüğünüz etkinliklere eklediğinizde faydalı hale gelir. Sprint planlaması: Gerçekçi olarak kaç öğeyi çekebileceğinizi tahmin etmek için çıktı geçmişinizi kullanın. "Son 8 sprintte sprint başına 6-9 öğe tamamladık" hikaye puanı toplamlarını tartışmaktan daha temelli bir yaklaşımdır. Etkili planlama oturumları yürütme hakkında daha fazla bilgi için sprint planlama rehberimize göz atın. Günlük scrum: Durum güncellemelerinden akışa geçin. "Ne yaşlanıyor?" "dün ne yaptın?"dan daha iyi bir sorudur. Bir öğe 7 günlükse ve 85. yüzdelik döngü süreniz 10 günse, ekip bunun üzerine swarming yapmalıdır. Sprint incelemesi: Paydaşlara döngü süresi trendinizi ve SLE performansınızı gösterin. "Bu sprintte öğelerin %85'ini 10 gün içinde teslim ettik, geçen ayki %72'den yukarı" şeffaflık yoluyla güven oluşturur. Sprint retrospektifi: Akış metriklerinin en çok karşılığını verdiği yer burasıdır. Kümülatif akış diyagramı, kod incelemesinde biriken iş veya QA toplantılara çekildiğinde açlık çeken bir test aşaması gibi burndown grafiğinde görünmez olan darboğazları gösterir.

Team members pointing at a large wall chart showing a cumulative flow diagram with colorful bands representing different workflow stages

Akış metrikleri vs. hız: kafes dövüşü değil

Hız bozuk değil, sadece sınırlı. Sprint seviyesindeki konuşmalar için dahili bir planlama aracı olarak iyi çalışır. Sorun, ekipler onu teslimat taahhütleri için kullandığında, ekipler arasında karşılaştırdığında veya bir performans metriği olarak ele aldığında başlar. Akış metrikleri hızın cevaplayamadığı soruları yanıtlar:

"Bu ne zaman bitecek?" Döngü süresi yüzdelikleri olasılıksal cevaplar verir.
"Neden işler bu kadar uzun sürüyor?" WIP ve iş öğesi yaşı size işin nerede takıldığını gösterir.
"Bu tarihe taahhüt edebilir miyiz?" Çıktı geçmişini kullanan Monte Carlo simülasyonları size güven seviyeleri verir.

Pratik yaklaşım: ikisini de kullanın. Ekibiniz için işe yararsa sprint planlaması için hızı koruyun. Teslimat tahmini ve süreç iyileştirme için akış metriklerini ekleyin.

Ekipleri tökezleten hatalar

Ekipleri karşılaştırmak için akış metriklerini kullanmayın

A Ekibinin 5 günlük döngü süresi, B Ekibinin 12 günlük döngü süresinden "daha iyi" değildir. Farklı bağlamlarda farklı insanlarla farklı işler yapıyorlar. Akış metriklerini kendi gelişiminiz için kullanın, lider tabloları için değil.

Her şeyin pahasına çıktı miktarını optimize etmek. Ekipleri daha fazla öğe kapatmaya itmek, küçük işleri seçmeye, hikayeleri yapay olarak bölmeye veya kalitede köşeleri kesmeye yol açar. Çıktı miktarı bir tanı aracıdır, hedef değil. İş öğesi yaşını çok geç olana kadar görmezden gelmek. Döngü süresi size yalnızca bitmiş iş hakkında bilgi verir. Devam eden öğeler için yaşı izlemiyorsanız, uyarı işaretlerini kaçırırsınız. Bunu panonuza koyun veya günlük scrum'da gündeme getirin. İş Akışı Tanımını atlamak. "Başladı" ve "tamamlandı"nın ne anlama geldiğine dair ortak bir anlayış olmadan, verileriniz tutarsızdır ve metrikleriniz güvenilmezdir. Mükemmel olması gerekmez, ancak var olması gerekir. Her şeyi ölçmek. 15 grafiğe ihtiyacınız yok. Dört akış metriği, bir döngü süresi dağılım grafiği ve belki bir kümülatif akış diyagramı, ihtiyacınız olanın %90'ını karşılayacaktır. Yalnızca cevaplamanız gereken belirli bir sorunuz olduğunda karmaşıklık ekleyin.

Birkaç ay sonra iyinin nasıl göründüğü

Akış metrikleriyle 3-6 ay süreyle devam eden ekipler birkaç şey fark etme eğilimindedir. Sprint planlaması daha hızlı hale gelir çünkü çıktı kapasite için açık bir başlangıç noktası sağlar. Retrospektifler daha spesifik aksiyon öğeleri üretir çünkü içgüdü yerine verilere bakıyorsunuz. En büyük değişiklik genellikle kültüreldir. Ekipler işe başlamayı düşünmeyi bırakır ve onu bitirmeyi düşünmeye başlar. Soru "sırada ne almalıyım?"dan "çizgiyi geçirmek için neye yardım edebilirim?"e kayar. İğneyi gerçekten hareket ettiren değişiklik budur.

İş öğesi yaşı ile başlayın

Eğer yalnızca bir akış metriği benimseyecekseniz, iş öğesi yaşını seçin. Bugün harekete geçebileceğiniz öncü bir göstergedir, faydalı olması için geçmiş verilere ihtiyaç duymaz ve günlük scrum'da kontrol etmek 30 saniye sürer.

Kollabe'nin planning poker gibi araçlar sprint planlamasının tahmin tarafında yardımcı olur, ancak akış metrikleri size tek başına tahminin sağlayamayacağı teslimat öngörülebilirliğini verir.

Evet. Birçok ekip her ikisini de kullanır. Hikaye puanları hala sprint planlama konuşmalarını yönlendirebilirken akış metrikleri tahmin ve süreç iyileştirmeyi yönetir. Zamanla bazı ekipler puanlara daha az güvendiklerini görür, ancak bir geçişi zorlamaya gerek yoktur.

Çoğu ekip Jira veya Azure DevOps ile başlayabilir, her ikisi de yerleşik döngü süresi raporlarına ve kümülatif akış diyagramlarına sahiptir. Daha derin analiz için ActionableAgile Analytics (Jira/Azure DevOps eklentisi olarak mevcuttur) başvurulacak araçtır.

İstatistiksel olarak anlamlı döngü süresi yüzdelikleri için 30+ tamamlanmış öğeyi hedefleyin. Çoğu ekip buna 3-4 sprintte ulaşır. İş öğesi yaşı geçmiş verilere ihtiyaç duymadığı için hemen faydalıdır.

Evet. Scrum Ekipleri İçin Kanban Rehberi, bu uygulamaları Scrum'a getirmek için özellikle Scrum.org tarafından yayınlandı. Kanban'ı benimsemenize gerek yok, sadece sürecinizin zaten ürettiği verileri takip edin.

10/02/2026 tarihinde son güncelleme