Pareto Tekniği (80/20) ile Backlog Yönetimi

İÇİNDEKİLER:
- Pareto Tekniği Nedir?
- Agile Yaklaşımlarda Pareto Tekniği
- Pareto Grafiği Nasıl Oluşturulur?
- Örnek Case Study

Problemsiz backlog olmaz. Her toplantıda bir kaç yeni Story eklense ay sonunda bir de bakmışsınız onlarca yeni Story yığılmış.. Bunlardan bir kısmını araya sıkıştırırsınız, bir kısmını da sonra çözmeye bırakırsınız. Hatta unutulsun diye eşelemediğiniz Story’ler bile vardır. 😄 Ama biz biliyoruz ki iyi bir Product Owner olmanın kriterlerinden biri de Product Backlog’un kontrolünü elinde bulundurmaktır. 😉

Şöyle bir düşünün. Yine bir Sprint Review öncesi Backlog item’larına uzun uzun baktığınız bir anda diyelim ki elinizde bir sonraki Sprint için bekleyen 20 tane Story var. Hangisiyle başlayacaksınız? Bir yandan müşteri tarafından istenilen özelliklerin yetişitirilmesi için uğraşırken yöneticinizden önceliklendirme için destek istediğinizde “hepsine başlayalım” der. Bir de hemen çözülsün ister. Hatta o an hangisi daha çok gündemde ise önce onlara odaklanmanızı önerebilir. Elbette bütün Story’lerin çözülmesi lazım ama hangisini önceliklendireceksiniz? 🤯

Elinizden gelenin en iyisini yapmaya çalışırken aslında daha azını yaparak daha verimli ve katma değerli olabileceğinizi biliyor muydunuz? 🤷‍♂️

İşte bu noktada ilk olarak hangi işlere başlanacağı konusunda karar almamıza yardımcı olabilecek istatiksek bir teknik olan Pareto karşımıza çıkıyor. ✨ Pareto İlkesi (80/20 kuralı olarak da bilinir), bir işin % 20’sini yaparak tüm işin % 80’ini yapabileceğiniz fikrine dayanır. Bu tekniğe göre, problemlerin büyük çoğunluğu (% 80) birkaç temel nedenden (% 20) kaynaklanır.

Örneklendirmek gerekirsek;

• Çalışanların %20’si, toplam kazancın %80’ini alır
• Hatalı ürünlerin %80’i hataların %20’sinden kaynaklanır
• Bir işletmenin kazandığı kârın %80'i, sağladıkları ürün veya hizmetlerin %20'sinden gelir
• Yazılım destek ekibine en çok iletilen hataların %20'sinin düzeltilmesi, şikayetlerin %80'ini azaltır veya ortadan kaldırır

Bu ilke, sadece Product Owner’ın değil, aynı zamanda tüm firmaların genel zaman yönetimi stratejisinde de çok önemli bir yere sahiptir.

Biz tekrar bizimle ilgili olan kısma geri dönelim 🙂 Bunu Product Management dünyasıyla ilişkilendirmek istiyorsanız, Business değerlerinin %80'inin, Feature’ların %20'sinden üretildiğini düşünün.

Agile yaklaşımlarda Pareto Tekniği

Agile yaklaşımlar, geleneksel yaklaşımlara kıyasla gereksinim değişikliklerine hızlı yanıt verdikleri için daha esnek ve pratiktir. Her bir çıktı (increment) sonrası test edilen sistem, kullanıcıların gereksinimleri değiştirmesine olanak tanır; bu da, artan kullanıcı katılımı nedeniyle proje başarısızlığı riskini en aza indirmek içindir.

İşte bu noktada, Pareto’nun gücünü deneyimleyerek etkili bir ürün stratejisi oluşturabilirsiniz. İstatiksel olarak biliyoruz ki birçok projede katma değerin %80'i proje görevlerinin %20'sinden sağlanır. Ürüne en fazla etkisi olacak görevlere öncelik vererek, çok daha hızlı ve daha az çabayla çok fazla değer sunmayı başarabilirsiniz. ⚡

Agile yaklaşımla yönetilen bir proje, bu avantajdan yararlanır ve yüksek değer getirecek görevlere öncelik vererek projenin daha iyi bir zaman diliminde ve daha kaliteli bir şekilde tamamlanmasını sağlar. Bu nedenle Pareto tekniği Product Owner’lar için kesinlike göz ardı edilmemesi gereken bir tekniktir. 🦸‍♂️

Pareto grafiği nasıl oluşturulur?

Product Owner, Pareto analizini kullanarak en önemli feature’ları ve ihtiyaçları belirleyerek görselleştirmek için bir Pareto şeması oluşturabilir. Bu sayede temel ihtiyaçlarla ve problemlerle nasıl başa çıkılacağını görselleştirir.

PMBOK’a göre ise Pareto grafiği, proje ekibinin en fazla sayıda soruna neden olan süreçleri önceliklendirmek için adımlar atmasına yardımcı olmak için kalite aşamasında kullanılan bir teknik olarak bahseder.

Pareto Analizini kullanarak odaklanmanız gereken öncelikli işleri belirlemek için aşağıdaki şekilde bir bar chart oluşturabilirsiniz.

1. X ekseninde nedenlerin ve Y ekseninde adet içeren bir dikey bar chart oluşturulur.
2. X eksenindeki feature’ları çoktan aza doğru sıralanır.
3. Her bir feature için kümülatif sayım yüzdesi azalan şekilde hesaplanır. {Neden Sayısı} / {Toplam Neden Sayısı}*100
4. Yüzdeleri %100'den %0'a 10'luk artışlarla azalan ikinci bir Y ekseni oluşturulur.
5. Her nedenin kümülatif sayım yüzdesi X eksenine çizilir.
6. X eksenine paralel uzanan Y ekseninde %80 oranında bir çizgi çizilir.
7. Son olarak, X ekseni üzerindeki eğri ile kesişme noktasındaki çizgi aşağıda doğru devam ettirilir. X ekseni üzerindeki bu nokta, soldaki önemli nedenleri sağdaki daha az önemli nedenlerden ayırır.

Case: Operasyon ekibi için bir raporlama aracı ürünü geliştirilmesi

Current Situation: Bu yeni bir ürün ve temel özellikleri oluşturmak için Prodoct Owner olarak sınırlı zamanınız ve kaynağınız var. Tüm paydaşlarla ilk tur tartışmayı yaptıktan sonra sahip olduğunuz özelliklerin listesini aşağıda listeleyelim.

Custom reports: Dashboard’da en çok kullanılan raporlar dışında kişiler özel raporlar da oluşturması
E-posta yapılandırması: Eposta client’ı kurulup kişilerin raporları excel veya PDF formatında eposta olarak alması
Zamanlama Raporlaması: Günlük, haftalık, aylık vb. olaylar için raporlama yapısı oluşturulması
Logging: Raporların oluşturulmasında veya tesliminde yaşanabilecek hatalar için loglama yapısı kurulması
Diğer kaynaklarla entegrasyon: Harici uygulamalar ile (Slack, FTP) belirlenen ilgili channel’lara entegrasyon ile bilgi paylaşılması

Hızlı önceliklendirme adımları:
i.) Her özelliği alın ve doğru geliştirme sırasına koyun
ii.) Her bir öğe için beş kez “neden” sorusunu sorun
iii.) En az çaba ve maliyet gerektirecek değere göre öncelik verin
iv.) Her özelliğe bir ağırlık atayın

Bir Product Owner olarak, neyin acil, neyin önemli olduğuna ve yapılması gereken şeylerin %20'sinin ne olduğuna karar verirken her zaman ürün hedeflerinizin yanında firmanızın belirlediği uzun vadeli stratejileri de dikkate alırsanız değer belirleme konusunda çok daha başalırı olabilirsiniz.