Feature Önceliklendirme Framework'leri
1 Şubat 2026
RICE, ICE ve MoSCoW framework'lerinin formülleri, uygulama farkları ve hangi durumda hangisinin kullanılacağı.
RICE Skoru: Formül ve Uygulama
RICE, dört bileşeni çarptırıp bölen bir önceliklendirme formülüdür: (Reach × Impact × Confidence) ÷ Effort. Reach, bir özelliğin belirli bir zaman diliminde kaç kullanıcıya ulaşacağını sayısal olarak ifade eder. Impact ürün hedefine katkıyı derecelendiren bir skalada ölçülür; 0,25 (minimal) ile 3 (dönüştürücü) arasında bir değer kullanmak yaygın bir yaklaşımdır. Confidence, tahminlere olan güven düzeyini yansıtır; yeterli kullanıcı araştırması veya teknik analiz yoksa bu değer %100 yerine %50 yazılır.
Confidence değerini gerçekçi tutmak RICE'ın en önemli disiplinidir. Tüm kalemlere %100 yazmak hesabı şişirir ve en pahalı özelliği yapay olarak en üste taşır. Örnek hesap: 1.000 kullanıcıya ulaşacak, yüksek etki değeri 3 olan, %80 güvenle çalışacağı tahmin edilen ve 2 mühendis-hafta gerektiren bir özellik için RICE = 1.000 × 3 × 0,8 ÷ 2 = 1.200 puan. Bu sayıyı diğer özelliklerle karşılaştırmak, toplantıdaki "benim özelliğim daha önemli" tartışmasını somut bir zemine taşır.
ICE Framework: Hızlı Kararlar İçin
ICE, RICE'ın Reach bileşenini dışarıda bırakarak yalnızca Impact, Confidence ve Ease (kolaylık) çarpımından oluşur. Bu sadeleştirme, erken stage ekiplerde Reach verisinin henüz mevcut olmadığı durumlarda hızlı bir önceliklendirme yapmanın pratik yoludur. Her bileşen 1 ila 10 arası puanlanır ve üç sayının çarpımı skoru verir.
ICE'ın avantajı hızıdır; beyin fırtınası oturumlarında 10 özelliği birkaç dakikada sıralamak mümkündür. Dezavantajı ise Reach'i görmezden geldiği için düşük kullanıcı tabanına yüksek etki yapan ve geniş kitleye düşük etki yapan özellikleri eşit görebilmesidir. Bu nedenle RICE'a geçiş için yeterli veri biriktikten sonra ICE'ı geri çekip RICE'a geçmek ürün olgunluk sürecinin doğal bir adımıdır.
MoSCoW: Stakeholder Uyumu
MoSCoW, önceliklendirmeyi dört kategoriye böler: Must have (olmazsa olmaz), Should have (olursa iyi), Could have (fırsata göre) ve Won't have (bu dönem dışında). Sprint veya milestone planlamasında ekip ve paydaşlar arasında "ne yapıyoruz, ne yapmıyoruz" konusundaki anlaşmazlıkları çözmek için güçlü bir araçtır.
MoSCoW'un asıl değeri "Won't have" kategorisini açıkça belirlemesinde yatıyor. Ekiplerin sıkça düştüğü tuzak, tüm özellikleri "Must have" olarak işaretlemektir; bu durumda framework anlamsızlaşır ve milestone sürekli kayar. "Bu döngüde bu özelliği yapmıyoruz" cümlesini bir karar olarak kayıt altına almak, aynı tartışmanın bir sonraki sprintte yeniden açılmasını önler. Paydaş uyumu açısından ise "Won't have" listesi, neyin neden ertelendiğini şeffaf biçimde gösterir ve beklenti yönetimini kolaylaştırır.
Hangi Framework Hangi Durumda
Tek bir framework her duruma uymaz; durumun gerektirdiğine göre seçim yapılmalıdır. Yeterli kullanım verisi ve ayrıntılı büyüme hedefleri olan orta-ileri aşama ekipler için RICE en güvenilir seçenektir çünkü Reach ve Confidence'ı zorlar ve ekibi veri toplamaya iter. Erken aşama veya zaman baskısı altındaki ekipler için ICE, kısa vadeli kararları hızlandırır. Çok sayıda paydaşın dahil olduğu sprint planlaması veya yeni ürün kapsamı müzakerelerinde ise MoSCoW stakeholder uyumunu tesis eder.
Kano modeli bu üçünün tamamını tamamlayan ayrı bir araçtır; temel beklentiler ile delighter'ları ayırır. Temel beklentiler yokluğunda şikayet yaratır ama varlıklarında memnuniyet artırmaz; delighter'lar yokken şikayet edilmez ama varsa memnuniyeti belirgin biçimde artırır. Productboard, Linear ve Jira gibi araçların tamamında RICE veya ICE skorları özel alan (custom field) olarak eklenebilir ve filtre görünümlerinde kullanılabilir.
Sık Sorulan Sorular
RICE ve ICE aynı anda kullanılabilir mi? Evet. ICE'ı hızlı ön eleme için, RICE'ı kazanan adayların daha derin analizinde kullanmak pratik bir hibrit yaklaşımdır.
MoSCoW'daki "Won't have" bir özellik hiç yapılmayacak mı? Bu dönem yapılmayacak anlamına gelir; bir sonraki milestone veya sprint planlamasında yeniden değerlendirilebilir.
Kano analizi ne sıklıkla yapılmalı? Yeni bir özellik kategorisi veya segment genişlemesi öncesinde yapmak en uygunudur; mevcut kullanıcıların beklentileri zamanla değişebileceğinden yılda bir tekrar etmek önerilir.
Effort'u puanlamak için ne kullanılır? Ekibe göre değişir; bazıları mühendis-gün, bazıları hikaye puanı (story points), bazıları 1-5 skalası kullanır. Önemli olan ekip içinde tutarlı bir birim seçilmesidir.
Ürün yöneticisi yokken kim önceliklendirme yapar? Kurucu veya teknik kurucu-CEO bu rolü üstlenir; framework kullanımı sistematikleştirdiği için rollerin dağıtılması mümkün hale gelir. RICE puanını spreadsheet'te tutmak bu süreci belgesel hale getirir.
