Agile Portal

Kanban metrikleri

Agile dönüşüm yolculuğunda takımlar metrikleri kullanarak iyileştirme noktalarını belirleyebilir veya eksik noktaların farkındalığını artırabilirler. Kanban takımları da Scrum’daki gibi çeşitli tahminleme tekniklerini kullanarak PBI’larının büyüklüklerini tahminleyebilir. Fibonacci, T-shirt size vb. tahminleme teknikleri kullanılabilir. Kanban takımlarında tahminleme yapılabildiği hiç tahminleme de yapılmadan PBI’lar değer akışına dahil edilebilir. Hatta bu yöntem son zamanlarda Agile dünyasında #noestimating olarak da dile getirilmektedir. Yalnız bu yazımda tahminleme tekniklerinden değil de kanbanın ölçüm metriklerinden bahsedeceğim.

Kanban takımlarında kullanabileceğimiz temel olarak 4 tane metrik var diyebiliriz. Lead time, Cyctime, Work In Progress Limiti ve Throughput değerleri.

Lead time: Talep sahibinin ihtiyacı ilettiği andan itibaren lead time’ın sayacı başlamakta, talebin tamamlanması ile birlikte de sayaç durmakta ve lead time sonlanmaktadır. Talep sahibi talebi ilettikten sonra takım hemen ele alamasa da sayaç işlemektedir.

Cycle time: Takımın talep üzerinde çalışmaya başladığı andan talebin tamamlandığı ana kadar geçen süre cycle time olarak adlandırılmaktadır. Bu süre içerisinde çeşitli sebeplerden dolayı takım bloke olduğu ilerleyemediği talepler olacaktır. Tavsiyem bu tip blokeli işlerde de cycle time sayacının işlemesidir. Böylece cycle time ile ilgili iyileştirme noktalarını da farkındalığı artmış olacaktır.

Lead time ve Cycle time ölçümlerinde dikkat edilecek noktalardan birisi de iş tipleri göre ayrımlar yapılmasıdır. Bakım, Problem, Talep gibi iş tiplerini tek bir lead ve cycle time olarak ölçümlemek ve hepsinin ortalamasına bakmak yanlış yönlendirecektir. Bu sebeple ortalama lead ve cycle time belirlenirlen iş tipine göre belirlenmesi israf ve iyileştirme noktalarının belirlenmesi açısından daha sağlıklı olacaktır.

Ortalama lead/cycle time takip edilirken bir periyotun belirlenmedir. Her bir iterasyon sonunda ortalama lead/cycle time’daki değişiklikler takip edilebilir. Takip edilmesi için çizgi veya bar grafiği kullanılabilir.

Herbir PBI’ın lead/cycle time incelenirken aykırı olan taleplere odaklanılabilir. Taleplerin çoğunluğunu toplandığı bir  bölge olacaktır. Ama aykırı dediğim bazı talepler ise bu bölgenin üzerinde bulunacaktır. Öncelikli amaç aykırı olan taleplerin süresinin uzun olmasına sebep olan etkenlerin  belirlemesi olmalıdır. Bu tip aykırı talepleri görebilmek için scatter (saçılım) grafiği kullanılabilir. Örnek bir scatter grafiği de soldaki gibidir.

Work In Progress (WIP) Limiti: Kanban pratiklerinden birisi de limitledir. Work In Progress metriği de buradan geliyor. Takımların aynı anda birçok işle ilgilenerek hepsinde azar azar ilerleme katetmelerinin yerine limitleyerek daha odaklı ilerlemesi hedeflenmektedir. Bu sebeple her bir değer akışını ayrı ayrı bir limiti olmalıdır. Takımlar deneyimleyerek değer akışında yer alan istasyonlar için ideal WIP limitini belirleyebilir.

Throughput (Çıktı): Değer akışından geçen tamamlanmış PBI sayısıdır. Throughput’un da Türkçe karşılığı çıktıdır. Bu metriği de etkin bir şekilde kullanılabilmesi için iş tipine göre bakılması önemlidir. Belli bir periyotlarda da iş tipine göre tamamlanmış PBI sayısı takip edilebilir.

 

Image: kanbanize.com

 

Muhammed Lap

Bankacılık ve telekomünikasyon sektöründe 14+ yıldır sistem uzmanı, iş/sistem analisti, product owner, scrum master, agile proje yöneticisi ve agile koç rollerinde çalışmıştır. Elde ettiği tecrübeyi ise kurduğu AgilePortal.net’de paylaşmaktadır.

1 comment