Scrum Metrikleri

Veri ve bilgi dünyasında yaşıyoruz. Bu yüzden sorunları teşhis etme konusunda çoğu zaman sayılara ihtiyaç duyuyoruz. Bir çok direktör ve üst düzey yöneticiler de bu doğrultuda işlerin nasıl gittiğini görebilmek için sayılardan yardım alıyorlar. Ekiplerinin verimliliğini görebilmek için onlardan bazı ölçümler isterler. Bu ölçümler sadece üst yönetim istediği için yapılmamalıdır. Ekip öncelike kendisi için metriklerini tutumalıdır. Ekibin kendi durumunu görebilmesi, iyileşmede en büyük yardımcısı olacaktır. Bu yazı da bir Scrum takımının ölçmesi gerektiğini düşündüğün Scrum Metrikleri ‘nden bahsedeceğim.

Scrum Metrikleri Kim İçin ve Nasıl Tutulmalıdır?

Geleneksel çalışma modellerinde bir hiyerarşi olduğundan çoğu kez bu metrikler, üst yönetim tarafından istenir ve değerlendirilir. Oysaki Scrum ekiplerinin en önemli özelliği kendi kendini yönetebilmesidir (Self-Organized). Ekibin kendini geliştirebilmesi için işi nasıl yaptığını anlaması ve görmesi gerekir. Bunun en kolay yolu da Scrum Metrikleri ni tutmaktır.

Bir scrum ekibi, kapasitesini, hızını, eksik kaldığı süreçleri, tüm/kalan işlerini gözlemleyebileceği metrikleri tutabilmelidir. Ayrıca bu metrikleri geri besleme döngüsü oluşturmalıdır. Aksi takdirde metrikler doğruyu göstermez.

Güncel tutulan metrikler, ekip tarafından sürekli değerlendirilmelidir. Bu değerlendirme çalışmasının en güzel zamanı, Sprint Retrospective toplantılarıdır. Bu toplantılar, ekibin kendi kendini değerlendirmesine ve böylece de iyileştirmeye fırsat verir. Metrikler ise ekibe tespitler konusunda yardımcı olacaktır.

Ekip eğer Sprint Bülteni yayınlıyorsa, Scrum Metrikleri bu bülten içinde de yer almalıdır. Sprint bülteni, ekibin sprint içerisindeki yaptığı işi listeleyen ve basit düzeyde tutulan bir belgedir. Bu yüzden metrikler bültenlerin olmazsa olmazıdır.

Bir scrum ekibi sef-organized bir takım olsada, bu metrikler üst düzey yöneticiler için de bir gösterge olabilir. Ekibin çevik sürece ne kadar adapte olduğunu, destek olunması gerekilen bir durumun olup olmadığını tespit etmek için ekibin Scrum Metrikleri ni referans alabilir. Metriklerin yönetim tarafından yorumlanması konusunda dikkat edilmesi gerekilen bir konu vardır. Burada yapılabilecek en büyük hata, ekip metriklerini karşılaştırmaktır. Bir ekibi, başka bir ekip ile karşılaştırmak için ekibin metrikleri kullanılmamalıdır. Her metrik ait olduğu takım içinde değerlendirilmelidir.

En Önemli 7 Scrum Metrikleri

Peki bir scrum takımının ölçümlemesi gereken Scrum Metrikleri nelerdir?

• Velocity – Story Point Bazında
• Burn Down Chart
• Lead Time
• CFD – Cumulative Flow Diagram
• Committed vs Done
• Planned & UnPlanned
• Innovation & Defect Rate

NOT:
Bu yazımda genellikle terimleri İngilizce kullanmaya çalıştım. Metrikler hassas bir konu olduğu için herkesin aynı şekilde anlamasını bu yöntemle daha kolay sağlayacağımı düşünüyorum. Böylece bu yazı dışında diğer kaynaklardan da aynı terimlerle arama yapabilirsiniz. 🙂

Velocity – Story Point Bazında

Velocity, scrum takımının hızını gösteren bir değerdir. Sprint içerisinde ekip tarafından tamamlanan ve ürün sahibi (Product Owner) tarafından “DONE” olarak kabul edilen hikaye puanlarının (Story Point) sayısıdır. Bir başka değişle; ekibin çalışır bir yazılım (Increment) üretme yeteneği de diyebiliriz.

Bu metrik sayesinde, ekip bir spintte ne kadar büyüklükte iş alabileceğini tahmin edebilir. Böylece Sprint Planning toplantılarında velocity kadar iş almaya çalımalıdır.

Velocity, Product Owner (PO) tarafından da etkin bir şekilde kullanılabilir. Bir işin ne kadar sürede biteceğini hesaplamada Product Owner’a yardımcıdır. Örneğin PO’nun elinde 500 Story Point (SP)’lik bir iş olsun. Ekibin velocity değeri de 50 SP olsun. PO bu işin aynı ekip tarafından 10 sprintte bitebileceğini öngörebilir. (500 / 50 = 10 Sprint)

Ekip hızının zaman içinde nasıl geliştiğini izlemelidir. Yeni kurulan bir ekip, takım ilişkileri ve iş süreçlerini zamanla iyileştirdikleri için hızda bir artış görmeyi bekleyebilirler. Uzun zamandır çalışan bir ekip ise zaman içindeki tutarlı performansı sağlayabilmek için hızlarını takip etmelidir. Ortalama hızdaki bir düşüş genellikle takımın gelişim sürecinin bir kısmının yetersiz kaldığının bir sonraki retroda konuşulması gerektiğini işaret edebilir.

Burn Down Chart

Scrum ekipleri çıktı üretme ve geliştirmelerini sprintler halinde düzenler. Her sprintin başında ekip, Sprint Planning toplantısını yapar ve burada o sprint hangi işi yapabileceklerini taahhüt eder (Commitment). Sprint boyunca ne kadar iş yaptıklarını ve ne kadar iş kaldığını takip ederler. Ekibin burada Burn Down Chart kullanması, sprint için geriye ne kadar iş kaldığını görmeye oldukça yardımcı olacaktır.

Burn Down Chart ayrıca, scrum değerlerine de hizmet eder. Bu metrik ile ekip kalan işlerini ve zamanı net bir şekilde görebilecek böylece taahhüt ettiklerine odaklanmayı sağlayacaktır.

Lead Time

Lead Time teslim süresi anlamındadır. Yapılan işin müşteriye ne kadar sürede teslim edildiği ile ilgilidir. Scrum takımlarının bu metriği 2’ye ayırarak kullanmaları, doğru tespitlerin yapılmasına daha çok yardımcı olacaktır. 2’ye ayıtmak derken şunu demek istiyorum;

• Customer Lead Time (CLT)
• System Lead Time (SLT)

Customer Lead Time ile, iş müşteriden ne zaman geldi, müşteriye ne zaman teslim edildi tarih aralığını gösterir. System Lead Time ise, müşteriden gelen iş ne kadar sürede geliştirildi tarih aralığını gösterir.

Peki bu metriği bu şekilde 2’ye ayırmanın faydası nedir?

Aynı iş için geliştirme süresi ile müşteriye teslim etme süresi birbirinden farklıdır. CLT çok daha geniş bir zamanı içerir. Müşterinin talep etmesi ile başlayan ve işi canlıya alma ile son bulan bu süre, SLT’ı etkilememelidir. Geliştirmesi çok kısa sürecek bir iş, talep edildiği halde öncelik sıralamasında en altlardaysa, canlıya çıkıs süresi uzun olacaktır. Bu iki ayrımın yapılabilmesi için bu metriği bu şekilde 2’ye ayırmak daha doğru olacaktır.

CFD – Cumulative Flow Diagram

Cumulative Flow Diagram, daha çok Kanban board uygulayan ekiplerin kullandığı bir metriktir. Ekipteki iş akışının tutarlı olmasına yardımcı olur. High level açıklamak gerekirse; ekibin analiz, geliştirme, fonksiyonel test, kullanıcı testi gibi iş yapma süreçlerde ne kadar / kaç adet iş olduğunu gün bazında gösteren bir diagramdır.

CFD üzerinde her bir iş süreci farklı bir renkte ve bu süreçlerdeki task/item sayısı birbiri üzerine eklenerek gösterilir. Grafikte renklerin düzgün  ve hafif bir şekilde yükselmesi beklenir. Eğer ani bir yükselme alçalma veya bir sapma varsa, bu ilgili renkteki iş sürecinde hatalar olduğu anlamına gelir. Böylece ekip hangi iş sürecinde sorun yaşadığını (yavaşlık, aşırı yüklenme vs.) bu grafik sayesinde görebilecektir.

Kanban uygulayan ekiplerin, CFD ile birlikte, WIP Limit (Work in Progress Limit) uygulamasını kullanması işlerini oldukça kolaylaştıracaktır. WIP Limit ile iş süreçlerine minimum ve/ya maksimum iş yapma kuralları koymak, ekibin yavaşlama, aşırı yüklenme veya boşa geçen zamanı engellemelerine yardımcı olacaktır.

Aşağıda CFD nasıl hazırlanmalı ve nasıl okunması ile ilgili bir video paylaşıyorum.

Committed vs Done

Bir scrum takımı, Sprint Planning toplantısında, o sprint ne kadar iş yapacağını taahhüt (Commitment) eder. Her sprint sonunda da Sprint Review toplantısında hangi işleri yaptığını hangileri tamamlayamadığını gösterir. Bu toplantıları sürekli bu doğrultuda yapmak iyileşmeye katkı sağlamayacaktır. Ekibin commit ettiği işlerin yüzde kaçını tamamlayabildiğini görmesi, sıkıntı gördüğü durumlarda müdahale edebilmesi ve/ya önlem alabilmesi gerekir.

Committed & Done (C&D) metriği Velocity ile benzerlik gösterir diyebilirsiniz. Ama her ikisi de farklı bir amaca hizmet eder. Velocity takımın hızını gösterir, C&D takımın sözünde ne kadar durabildiği, sprint içinde planlanandan farklı veya beklenmedik birşey olup olmadığının tespitinde yardımcı olur.

Planned & UnPlanned

Sprint Planlama etkinliğinde planladığımız işlerimizin yanında sprint içinde gelen plansız işlerimiz de olabilir. Bu çok doğal bir durumdur. Takım sprint sonudan ne kadar planlı veya plansız ileri varmış, bunların birbirine oranı nedir gibi soruların cevabı için Planned & UnPlanned metriğini kullanabilir.

Bu metriği tutmak için sprint içinde yapılan tüm işleri “Planlı” ve “Plansız” olarak işaretlemek gerekir. Takım Sprint Planlama etkinliğinde planladığı işler “Planlı / Planned” olarak işaretler. Sprint içinde gelen acil işleri, yapılan için içinden çıkan yeni işleri veya önceliği değişen bir maddenin sprinte giren işler de “Plansız / UnPlanned” olarak işaretler.

Innovation & Defect Rate

Her scrum ekibinin ürettiği ürün yeni bir proje olmak zorunda değildir. Mevcut bir proje üzerinde hem geliştirme hem de hata kaydı çözen ekipler de oldukça fazla. Bu tarz çalışan ekiplerde fazla sayıda hata kayıtlarıyla uğraşmak genellikle motivasyon düşüklüğüne sebep olmaktadır. İnsan doğası gereği yeniliğe ihtiyaç duyar. 

Eğer bir ekip geliştirdiği ürün üzerinde ne kadar yenilik/yeni özellik yaptığını (Innovation,) ne kadar hata (Defect) çözdüğünü bilirse, hedeflerini, misyonunu, bakış açısını iyileştirmeye katkı sağlaycak şekilde yönlendirebilir.

Bu metrik, bir sprintte yapılan işlerin adet ve/ya size olarak ne kadarı innovation ne kadarı defect olduğunu gösteren bir histogramdır. Ekipler, çok basti düzeyde aşağıdaki görseldeki gibi dataları tutarak, bu metrikten faydalanabilirler.

İlkim Dilara KADAKALOĞLU