Gönderiler

Sprint hızı (velocity): nasıl takip edilir, tahmin yapılır ve yanlış kullanımdan nasıl kaçınılır

Tamamlanan story point'leri sprint başına gösteren yükselen bir çubuk grafik dizisi ve hız göstergesi kadranı bulunan bir sprint panosu çizimi, canlı mor ve mavi tonlarda modern düz editöryel stil, grafiği birlikte inceleyen küçük bir agile ekip

Kelly Lewandowski

Son güncelleme 07/06/20268 dk okuma

Velocity, hesaplanması en kolay agile metriğidir ve aynı zamanda en kolay bozulanıdır. Ekibinizin geçen sprint'te tamamladığı story point'leri toplarsınız. Hepsi bu. Sorun, birinin bu sayıyı bir hedef, bir verimlilik puanı ya da kesin bir teslimat sözü gibi görmeye başladığı anda ortaya çıkar. Velocity'nin tam olarak iki meşru işi vardır: bir iş yığınının kabaca ne zaman biteceğini tahmin etmenize yardımcı olmak ve ekibe bir sonraki sprint'e ne kadar iş çekeceği konusunda bir gerçeklik kontrolü sunmak. Bunun dışındaki her şey için kullanıldığında faydadan çok zarar verir. İşte bu iki işi nasıl iyi yapacağınız ve yanlış kullanımı yayılmadan önce nasıl fark edeceğiniz.

Sprint hızı (velocity) aslında nedir

Velocity, ekibinizin bir sprint'te tamamladığı story point sayısıdır. Tamamlanmış, sizin Definition of Done tanımınıza göre bitmiş demektir; "QA'de" ya da "neredeyse merge edildi" değil. Yarım kalan iş sıfır puan sayılır. Sonraki sprint'e sarkan bir story, başladığı sprint'te değil, gerçekten bittiği sprint'te puan kazanır. Tanımın tamamı bu. Velocity; eforun, saatlerin ya da insanların ne kadar çok çalıştığının bir ölçüsü değildir. Ekibinizin kendi story point para biriminde çıktının bir ölçüsüdür; tam da bu yüzden yalnızca o tek ekibin içinde bir anlam taşır.

Point'ler ekibe görelidir

Bir ekibin point'leri o ekibe göre kalibre edilmiştir. Bir ekibin 8'i, başka bir ekibin 3'üdür. Velocity karşılaştırmalarının çoğunu geçersiz kılan tek gerçek budur ve buna tekrar döneceğiz.

Nasıl hesaplanır (ve tek bir sayı neden yalan söyler)

Temel formül, son sprint'lerinizin ortalamasıdır: Ortalama velocity = tamamlanan toplam point ÷ sprint sayısı En az 3 sprint, ideal olarak 6 veya daha fazlasını kullanın ve yalnızca ekibin kabaca sabit kaldığı sprint'leri sayın. İşte gerçeğe yakın bir altı sprint serisi:

22, 28, 19, 31, 24, 26

Sprint başına tamamlanan point

Ortalama velocity

19–31

Gerçek aralık

Ortalama 25. Ama hiçbir sprint aslında 25 teslim etmedi ve gerçek dağılım 19 ile 31 arasında. Her sprint'i "25" üzerinden planlarsanız yavaş sprint'lerde fazla taahhütte bulunur, hızlı sprint'lerde ise eksik doldurursunuz. Ortalama bir sözleşme değil, bir konuşmanın başlangıç noktasıdır. Bu yüzden Sprint Velocity Hesaplayıcısı ortalamanın yanı sıra bir aralık ve bir tutarlılık puanı da raporlar. Son birkaç sprint'inizi yapıştırın; size yalnızca orta noktayı değil, o orta noktanın ne kadar güvenilir olduğunu da söyler. 24, 25, 26 gibi giden bir ekip, ikisi de 25 ortalamasına sahip olsa bile, 12, 38, 25 gibi giden bir ekipten çok farklı bir durumdadır.

Tahminleme: tek sayılar değil, aralıklar kullanın

İşte velocity tavsiyelerinin çoğunun yanlış gittiği nokta burası. Klasik hamle "backlog ÷ ortalama velocity = bitirmek için gereken sprint sayısı" şeklindedir. 200 point'lik bir backlog ve 25 ortalama velocity ile bu 8 sprint eder. Temiz, kendinden emin ve neredeyse kesinlikle yanlış; çünkü velocity'nizin hiç değişkenliği yokmuş gibi davranır. Velocity'nizin değişkenliği vardır, dolayısıyla tahmininizin de olmalıdır. Basit ve dürüst yöntem üç tahminli yöntemdir: muhafazakâr bir velocity, olası bir velocity ve iyimser bir velocity ile tahmin yaparsınız.

Senaryo	Kullanılan velocity	200 point'lik backlog
Muhafazakâr	En yavaş 3 sprint'inizin ortalaması (~22)	~10 sprint
Olası	Genel ortalama (25)	8 sprint
İyimser	En hızlı 3 sprint'inizin ortalaması (~28)	~7 sprint

Artık bir paydaşa, sonradan geri almak zorunda kalacağınız tek bir sayı yerine "7 ila 10 sprint, büyük olasılıkla 8" diyebilirsiniz. Mike Cohn'un ve başkalarının uzun süredir savunduğu gibi, "bunun sprint 7 ile sprint 10 arasında biteceğinden %90 eminiz" gibi bir ifade, sahte kesinlikten hem daha kullanışlı hem de daha savunulabilirdir.

Her zaman bir aralık söyleyin

Birisi sizden tarih istediğinde, ona iki tarih verin: iyimser olanı ve muhafazakâr olanı. Bir aralık belirsizliği dürüstçe iletir ve gerçeklik neredeyse her zaman olduğu gibi ortada bir yere düştüğünde sizi korur.

Gerçek olasılıklar isteyen ekipler için bir sonraki adım Monte Carlo simülasyonudur. Elle seçilmiş üç senaryo yerine, geçmiş sprint'lerinizden rastgele örnekleyerek binlerce simüle edilmiş gelecek üretir ve sonuçları yüzdelik dilimler olarak raporlar: 50'inci yüzdelik (medyan) bitiş, 85'inci, 95'inci. "Sprint 9'a kadar bitirme şansımız %85" ifadesi, herhangi bir ortalamanın sunabileceğinden çok daha güçlü bir iddiadır. Tek bir nokta tahminine değil, bir dağılıma ihtiyacınız var. Bir başlangıç noktasından bir bitiş bayrağına doğru açılan bir belirsizlik konisi çizimi, mavi ve mor gradyan bantlar halinde birden fazla olasılık yolu, modern düz vektör stili, metin veya sayı yok

Bir başlangıç noktasından bir bitiş bayrağına doğru açılan bir belirsizlik konisi çizimi, mavi ve mor gradyan bantlar halinde birden fazla olasılık yolu, modern düz vektör stili, metin veya sayı yok

Ekipler velocity'yi nasıl yanlış kullanır

Scrum.org "Story Points are not the Problem, Velocity is" başlıklı bir yazı yayımlayacak kadar ileri gitti. Point boyutlandırması çoğunlukla zararsızdır; asıl zarar, yöneticilerin ortaya çıkan velocity sayısıyla yaptıklarından gelir. Dikkat edilmesi gereken dört başarısızlık biçimi şunlar.

⚖️Ekipleri karşılaştırmak

Ekip A 40 yapar, Ekip B 25 yapar, yani Ekip A "daha verimli." Yanlış. Point'ler ekibe göredir, dolayısıyla bu karşılaştırma hiçbir şey ölçmez. Yalnızca Ekip B'ye sayıyı şişirmeyi öğretir.

📈Bir verimlilik metriği olarak

Velocity, insanların üzerinden değerlendirildiği bir sayıya dönüştüğü an, çıktıyı ölçmeyi bırakır ve ekibin ne kadar baskı hissettiğini ölçmeye başlar. Goodhart yasası iş başında.

🎯Bir taahhüt olarak

"Geçen sprint 30 yaptın, o yüzden 30'a taahhüt ver." Bu, bir tahmini bir kotaya çevirir ve ekibi sayı güvenle tutturulana kadar tahminleri şişirmeye iter.

🎲Tek bir sprint'ten

Tek bir sprint gürültüdür. Bir tatil, bir kesinti ya da çetrefilli tek bir bug onu fena halde sallar. Velocity yalnızca birkaç sprint'e yayılan bir eğilim olarak bir anlam taşır.

Ortak nokta şu: her yanlış kullanım velocity'yi ekibin kullandığı bir araçtan ekibin üzerinden yargılandığı bir hedefe çevirir. Bu dönüşüm gerçekleştiğinde sayı manipüle edilir ve başladığınız dürüst sinyali kaybedersiniz.

Şişirme ölüm sarmalı

Bir ekibe velocity'sini büyütmesi için baskı yapın; bunu anında, aynı işi sessizce daha yüksek boyutlandırarak yapar. Velocity tırmanır, hiçbir şey daha hızlı teslim edilmez ve artık geçmiş verileriniz tahminleme için zehirlenmiştir. Optimize ettiğiniz metrik, yarayışlı olduğu tek şeyi yok eder.

Velocity'yi doğru yapmak

Yalnızca bir iç planlama yardımcısı olarak kullanıldığında ve başka bir şey olarak değil, velocity hak ettiği yeri kazanır. Onu dürüst tutmak için kısa bir kontrol listesi:

Yalnızca Definition of Done tanımınıza göre tamamen biten işi sayın.

6+ sprint üzerinden ortalama alın ve tek bir sayıyı değil eğilimi izleyin.

Tahmini aralıklar veya yüzdelik dilimlerle yapın, asla tek bir "biteceği tarih" ile değil.

Büyük ekip değişikliklerinden sonra yeniden temel alın; eski velocity taşınmaz.

Velocity'yi asla ekipleri ya da bireyleri karşılaştıran bir slaytta göstermeyin.

Tahminleme konuşmasını sürdürün; tartışma point'lerden daha önemlidir.

Son madde, ekiplerin unuttuğu maddedir. Velocity, iyi tahminlemenin bir yan ürünüdür, amacı değildir. Planning poker'ın değeri, gizli karmaşıklığı sprint ortasında sizi vurmadan önce yüzeye çıkaran konuşmadır. Ortaya çıkan sayı yalnızca defter tutmaktır.

Velocity tek seçeneğiniz değil

Ekibinizde velocity sürekli silah olarak kullanılıyorsa ya da story'leriniz point'lerin sabit kalamayacağı kadar farklı boyutlarda değişiyorsa, seçenekleriniz var. Bazı ekipler tahminlemeyi tamamen bırakır ve doğrudan throughput'tan tahmin yapar. Daha hafif bir hamle ise velocity'yi tutmak ama iyi yapamadığı kısımlarda akış (flow) metriklerine yaslanmaktır. Throughput (sprint başına biten öğe sayısı) ve cycle time (bir öğenin başlangıçtan bitişe ne kadar sürdüğü), teslimatı tahminler yerine gerçek zaman damgalarıyla ölçer.

Soru	En iyi metrik
Bir sprint'e ne kadar iş çekilmeli	Velocity veya throughput
Bu backlog ne zaman bitecek	Velocity/throughput üzerinde Monte Carlo
İş neden bu kadar uzun sürüyor	Cycle time ve devam eden iş (WIP)
Zamanla iyileşiyor muyuz	Cycle time eğilimi

Olgun ekiplerin çoğu sonunda ikisini birden kullanır: sprint düzeyindeki konuşma için velocity, teslimat tahmini ve darboğazları tespit etmek için akış metrikleri. Farklı soruları yanıtlarlar ve hiçbiri bir verimlilik skor tablosu değildir.

Sonuç olarak

Velocity bir hız göstergesi değil, bir el fenerdir. Ekibin kabaca ne kadar iş üstlenebileceğini ve bir iş yığınının kabaca ne zaman biteceğini görmesine yardımcı olur. Onu işe değil insanlara doğrultursanız, gerçeği söylemeyi bırakır. Onu birkaç sprint'e yayarak takip edin, aralıklarla tahmin yapın ve ekibin içinde tutun. Sayıların hızla hesaplanmasına ihtiyaç duyduğunuzda, Sprint Velocity Hesaplayıcısı son birkaç sprint'inizi birkaç saniye içinde bir ortalamaya, gerçekçi bir aralığa, bir tutarlılık puanına ve bir backlog tahminine dönüştürür. Onu besleyen tahminleme tarafında ise planning poker, odağı ait olduğu yerde tutar: skor tablosunda değil, konuşmada.

Kabaca bir ortalama için en az 3, ama tahminleme için ona güvenmeden önce 6 veya daha fazlası. Bundan azı, tek bir sıra dışı sprint'in her şeyi çarpıtmasına yol açar. Ekip de bu sprint'ler boyunca makul ölçüde sabit olmalıdır.

Yalnızca o öğeler point olarak tahminlendiyse ve sprint içinde bittiyse. Birçok ekip bug'ları ve destek işini point'siz bırakır ve onları ayrı takip eder; bu da velocity'yi planlanan özellik teslimatına odaklı tutar. Bir yaklaşım seçin ve tutarlı kalın ki geçmişiniz karşılaştırılabilir kalsın.

Story point'ler her ekibe göre kalibre edilir, dolayısıyla bir ekibin 5'i başka bir ekibin 13'üdür. Ham sayıları karşılaştırmak gerçek hiçbir şey ölçmez ve ekipleri tahminlerini şişirmeye zorlar. Ekipler arası bir görünüme ihtiyacınız varsa, point'lere değil teslim edilen sonuçlara ya da cycle time'a bakın.

Hayır. Velocity, teslim edilen değeri ya da harcanan eforu değil, ekibe özgü bir birimde çıktıyı ölçer. Bir ekip, daha kullanışlı hiçbir şey teslim etmeden, yalnızca işi daha yüksek boyutlandırarak velocity'sini artırabilir. Onu bir planlama girdisi olarak görün, asla bir performans metriği olarak değil.