Tüm rehberlere geri dönPlanning Poker

Hikâye puanı örnekleri: 1'den 13'e referans ölçeği

Ekibinizin işleri karşılaştırmasına, varsayımları sorgulamasına ve kendi referans hikâyelerini seçmesine yardımcı olacak altı backlog örneği.

Tarafından:Alexandr Voloshyn 6 dk okumaYayınlandı: 26 Eylül 2026
Üzerinde 1, 2, 3, 5, 8 ve 13 yazan altı tahmin kartı ve artan belge kartları yığınları

Hikâye puanı tahmini; çaba, karmaşıklık ve belirsizlik göz önüne alınarak bir ekip için işin göreli büyüklüğünü ifade eder. Bu nedenle tamamlanmış, tanıdık bir öğe bir sonraki öğeyi tartışırken yararlı bir referans olur. Atlassian’ın tahmin rehberi bu göreli yaklaşımı açıklar.

Örneğin, bir ekip tanıdık bir ayar değişikliğine 2, yeni bir bildirim iş akışına ise 5 puan verebilir. İşin anlamlı sorusu: farkı açıklayan ek iş nedir?

Aşağıdaki örnekler, paylaşılan belge çalışma alanı geliştiren kurgusal bir ekibe aittir. Bunlar özellikler için standart fiyatlar değil; tartışma için başlangıç noktalarıdır. Ekibiniz makul şekilde farklı değerler seçebilir.

Bir ekibin ölçeğinde altı örnek

Bu ekibin zaten bir bileşen kütüphanesi, çalışma alanı izinleri, bildirim servisi ve mevcut iş akışları için otomatik kontrolleri olduğunu varsayın. Her tahmin, uygulama, inceleme ve ekibin 'tamamlandı' tanımını karşılamak için gereken kontrolleri içerir.

PuanlarBacklog maddesiBu örnekte dahil olanlarBu ekibin buraya yerleştirme nedeni
1Boş bir etkinlik akışını açıklaOnaylanmış metin ve mevcut boş-durum bileşeni; yeni davranış yokAz etkilenmiş durumu olan küçük, tanıdık bir değişiklik
2Çalışma alanı yöneticilerinin paylaşılan görüntü adını değiştirmesine izin verMevcut ayar formu, API ve yönetici izin kontrolü; doğrulama ve kaydedilen/hata durumlarıBirkaç davranış kontrolü olan tanıdık bir yol; ekibin referans maddesi
3Belgeleri sahiplerine göre filtreleMevcut filtre bileşeni ve API desteği; sıfırlama davranışı ve boş sonuçlarReferanstan daha fazla etkileşimli UI durumu, bilinen bir veri yolu ile
5Bir belge sahibine erişim isteği olduğunda bildirMevcut iletim servisi; izin kontrolleri, bildirim içeriği, çoğaltma işlemi ve isteğe geri bağlantıBirkaç mevcut parça doğru şekilde bir arada çalışmalı
8Bir çalışma alanında belge sahipliğini devretYeni devretme işlemi; izin değişiklikleri, eş zamanlı düzenlemeler ve denetim kaydıDaha geniş bir durum geçişi ve dikkatli anlaşma gereken hata senaryoları
13Bir klasörü ve belgelerini başka bir çalışma alanına taşıHedef izinleri, bağlantılar, kısmi hatalar ve kurtarma davranışıBu ekip için tek bir uygun maddede çok fazla bağlantılı karar; bölme tartışılmalı

Altyapı varsayımları önemlidir. Bildirim servisi olmayan bir ekip, 5 puan örneğinde ek iş tahmin eder. Kanıtlanmış sahiplik devri operasyonu olan bir ekip, o maddeyi daha düşük puana koyabilir.

Bu sayılar bir formül değildir. UI ekranlarını, uç noktaları veya kabul kriterlerini saymak tahminleri güvenilir şekilde çoğaltmaz.

Kapsam tahmini nasıl değiştirir

“Bir çalışma alanı görüntü adını değiştir” örneğini düşünün. Tablo, ayarlarda gösterilen paylaşılan etiketi düzenleyen bir yöneticiyi, mevcut bir güncelleme uç noktası ve izin kontrolünü varsayar.

Şimdi kabul koşullarını değiştirin:

VersiyonKapsamÖrnek tahmin
AÇalışma alanı ayarlarında gösterilen etiketi değiştir; mevcut kaydetme işlemini kullan2
BDavet içeriğini ve önbelleğe alınmış gezinmeyi de güncelle; güncelleme sadece kısmen başarılı olursa bu alanları tutarlı tut5
Cİsim aynı zamanda genel çalışma alanı URL'sini belirler; eski bağlantıları koru ve çakışmaları yönetAçıklık için durakla, sonra muhtemelen 8 veya böl

C versiyonu boyutlandırma sorusu öncesi bir ürün sorusu doğurur: Yeniden adlandırma URL'yi tamamen değiştirmeli mi? Kararlı bir URL tutmaya karar vermek, ek işin çoğunu ortadan kaldırabilir.

Bir katılımcı 2 oy verirken diğeri 8 oy verirse, herkesin dahil ettiği davranışı açıklamasını isteyin. Her iki taraf da farklı versiyonlar hakkında tutarlı şekilde mantık yürütebilir. Tekrar oy vermeden önce kabul koşullarını yeniden yazın.

Ekibinizin hatırladığı referans hikâyeleri seçin

Belirgin sınırları olan iki veya üç tamamlanmış madde seçin. Küçük tanıdık bir değişiklik, orta seviye bir iş akışı ve daha büyük ama anlaşılan bir değişiklik, ekibe tek bir soyut sayıdan daha faydalı karşılaştırmalar sunar.

Her referans için kısa bir not tutun:

  • Sağladığı kullanıcı sonucu neydi?
  • Hangi sistemler ve durumlar değişti?
  • Hangi inceleme ve doğrulama işleri vardı?
  • Hangi varsayımlar işi kolay veya zor yaptı?

Sonra yeni işi en yakın referansla karşılaştırın. “Bu ayar değişikliğimize benziyor ama iki izin yolu ekliyor” ifadesi insanlara somut bir tartışma noktası verir.

Ekipte ortak teslim geçmişi yoksa, geçici referans olarak iyi anlaşılan bir madde seçin. Teslim sonrası bunu tekrar gözden geçirin ve varsayımları görünür tutun. Ekip birlikte öğrenmeden mükemmel bir ölçek oluşturmanıza gerek yoktur.

Bu tahmin notunu bir backlog maddesine kopyalayın

Aşağıdakini backlog veya ekip notlarında tartışma desteği olarak kullanın:

Kullanıcı sonucu:
Dahil edilen davranış:
Açıkça hariç tutulan:
En yakın tamamlanmış referans:
Bunu daha küçük veya büyük yapan:
Kapsamı değiştirebilecek bilinmeyenler:
Karar: tahmin / böl / araştır
Hazırsa kararlaştırılmış tahmin:
Sonraki açıklama ve sahip, gerekiyorsa:

İşte erişim bildirimi maddesi için doldurulmuş bir örnek:

Kullanıcı sonucu: belge sahibi, bir çalışma alanı üyesinin erişim talep ettiğini öğrenir ve isteği açabilir.

Dahil: mevcut bildirim servisini kullanmak, alıcının izinlerini kontrol etmek, bekleyen isteğe bağlantı vermek ve teslimat yeniden denendiğinde çoğaltılmış bildirimleri engellemek.

Hariç: hatırlatma e-postaları, günlük özetler ve otomatik erişim verme.

Referans: 2 puanlık ayar değişikliğimiz tek bir tanıdık kayıt yolunu kullanır. Bu madde ise istek, izin ve teslimat yollarını birleştirir; dolayısıyla daha fazla koordinasyon ve hata senaryosu içerir.

Açık soru: Hizmet zaten çoğaltılmış teslimi engelliyor mu? Bildirim servisi sorumlusu bizim tahmini onaylamadan önce bunu teyit edecek.

Tablodaki kurgusal senaryoda, bu kontrol yeniden kullanılabilir teslim desteğini doğrular ve ekip 5 puanda uzlaşır. Olmazsa, ekip aynı sayıyı kullanmadan önce ek iş hakkında tartışmalıdır. Referans karşılaştırmayı açıklar; sonucu hesaplamaz.

Toplantı akışı için adım adım Planning Poker kılavuzunu kullanın. Özel oylama, farkların tartışılması ve sonraki tur sonucunun seçilmesini kapsar.

Bir sayı henüz faydalı olmadığında

Bilinmeyen bir unsur işin doğasını değiştirdiğinde açıklamaya geri dönün. “Bildirim hangi metni kullanmalı?” sorusu “Hedef çalışma alanı dış kullanıcı kabul ediyor mu?” sorusundan farklı bir belirsizliktir.

Klasör taşıma örneği için ekip önce daha küçük bir kullanıcı sonucunda anlaşabilir: kullanıcının yönettiği çalışma alanları arasında bir belge taşı. Bu ilk parça hala net hedef izinlerine, korunmuş erişim kurallarına ve kesilen taşıma işleminin belge kaybına veya yanlış kişilere açığa çıkarmamasına yönelik güvenli hata yönetimine ihtiyaç duyar. Belge gruplarını taşımak ayrı bir madde olabilir. Grup büyüklüğünü azaltmak işi daraltır; hata yönetme ihtiyacını ortadan kaldırmaz.

Bölme sonrası, her maddeyi ayrı değerlendirin. Yeni sayılar toplamda tekrar 13 olmak zorunda değildir: ekip kapsamı değiştirmiş ve iş hakkında daha fazla bilgi edinmiştir.

Ekiplerin sıkça sorduğu sorular

3 puanlık bir hikâye kaç saattir?

Evrensel bir dönüşüm yoktur. Buradaki örnekler kurgusal ekip içindeki işleri karşılaştırır. Teslimat tahmini gerekiyorsa kendi teslimat geçmişiniz ve mevcut kapasitenizi kullanın; belirsizlikleri puan etiketinden ayrı tartışın.

Her hata 1 puanlık maddedir mi?

Hayır. Neden bilinen, tekrarlanabilir bir görüntü hatası, nedeni hala bilinmeyen aralıklı veri kaybından farklıdır. Ne tahmin ettiğinizi netleştirin: düzeltme mi, araştırma mı yoksa her ikisi mi.

Her ekip 13 puanlık bir hikâyeyi bölmeli mi?

Hayır. Burada 13, bu özel ekibin inceleyip bölmek istediği işi işaret eder. Ekibinizin sınırı referanslarına ve bir maddeyi anlama ile teslim etme yeteneğine bağlıdır.

Referanslarınızı Planning Poker’a taşıyın

Birkaç gelecek madde seçin, kabul sınırlarını yazın ve yanlarında referans hikâyelerinizi tutun. Ekibin tahmin oturumu için Agilo Planning Poker’ı kullanın.

Maddeler tartışmaya hazır olduğunda Planning Poker odası oluşturun

Rehberi uygulamaya koy

Bekleyen işleri tek bir Planning Poker odasında toplayın

Takımın bağımsız oy vermesine izin verin, tahminleri birlikte açın ve farkları tartışmayı yönlendirmek için kullanın.

Planning Poker’ı keşfet