Kullanıcı Hikayesi (User Story) Yazımı

💬 Prompt

Aşağıdaki gereksinim için kullanıcı hikayesi (user story) ve kabul kriterleri yaz:

BAĞLAM:
- Proje / ürün: [PROJE ADI]
- Modül / özellik: [HANGI MODÜL]
- Hedef kullanıcı rolü: [PERSONA - MÜŞTERI / ADMIN / SATıŞ TEMSILCISI vs.]
- İş değeri: [NEDEN ÖNEMLI]

GEREKSİNİM ÖZETİ:
[MÜŞTERI VEYA PAYDAŞTAN GELEN HAM GEREKSİNIM METNİ]

YAPI (INVEST kriterlerine uygun):

1. BAŞLIK
- Kısa, aksiyon odaklı (5-10 kelime)
- Örnek: "Şifre sıfırlama e-posta doğrulama"

2. HİKAYE METNI (standart format)

"[ROL] olarak
[İHTİYAÇ / AKSIYON] istiyorum
çünkü [İŞ DEĞERI / FAYDA]"

ÖRNEK:
"Kayıtlı bir müşteri olarak
Şifremi e-posta üzerinden sıfırlayabilmek istiyorum
çünkü parolamı unuttuğumda müşteri hizmetlerini aramadan erişimimi geri kazanmak istiyorum."

3. KABUL KRITERLERI (Given-When-Then formatı)

Her hikaye için 3-7 senaryo. Her senaryo 3 bölümden oluşur:

- GIVEN: Başlangıç durumu (ön koşullar)
- WHEN: Gerçekleşen aksiyon / olay
- THEN: Beklenen sonuç

ÖRNEK KABUL KRİTERLERİ:

Senaryo 1 — Başarılı şifre sıfırlama:
- GIVEN kayıtlı bir müşteriyim ve e-posta adresim sistemde kayıtlı
- WHEN şifre sıfırlama sayfasında e-posta adresimi girip "Gönder" butonuna basarsam
- THEN sisteme kayıtlı e-posta adresime 15 dakika geçerli, tek kullanımlık bir şifre sıfırlama linki gönderilir

Senaryo 2 — Kayıtlı olmayan e-posta:
- GIVEN sistemde kayıtlı olmayan bir e-posta adresim var
- WHEN şifre sıfırlama talep edersem
- THEN güvenlik gerekçesiyle aynı başarılı mesajı görürüm ancak gerçek bir e-posta gönderilmez

Senaryo 3 — Süresi dolmuş link:
- GIVEN 15 dakikadan eski bir sıfırlama linkine sahibim
- WHEN bu linke tıklarsam
- THEN "Link süresi doldu" mesajı görür ve yeni link talep etme seçeneği sunulur

4. ADDITIONAL (ek bilgi - INVEST)

I - Independent (Bağımsız):
- Diğer hikayelerden bağımsız geliştirilebilir mi
- Bağımlılık varsa belirt

N - Negotiable (Pazarlanabilir):
- Detaylar geliştirme sırasında ayarlanabilir
- Dondurulmuş değil

V - Valuable (Değerli):
- İş değeri net
- Kullanıcıya somut fayda

E - Estimable (Tahmin edilebilir):
- Ekip story point (1, 2, 3, 5, 8) verebilir
- Büyükse (13+) daha küçük parçalara böl

S - Small (Küçük):
- Tek sprint'te bitirilebilir (2 hafta)
- Büyükse Epic → Story dönüşümü

T - Testable (Test edilebilir):
- Kabul kriterleri objektif
- Pass/fail ölçülebilir

5. TEKNİK DETAY

- UI / UX notları (ekran değişiklikleri)
- API endpoint gereksinimleri
- Veritabanı tablo değişiklikleri
- 3. taraf servis entegrasyonu (varsa)
- Mevcut sistemle etkileşim

6. KAPSAMA DAHİL OLMAYAN (NOT IN SCOPE)

- Bu hikaye ile yapılmayacaklar
- Ayrı hikayede ele alınacaklar
- Örnek: "SMS ile doğrulama bu story kapsamında değildir"

7. DIZAYN / MOCKUP REFERANSI

- Figma / Sketch link
- Sayfa numaraları
- Ekran akışı diyagramı

8. KULLANıM DURUMU / İSTATISTIK

- Bu işlemi kaç kullanıcı yapacak (tahmini)
- Ne sıklıkla
- Mevcut süreçteki pain point

9. KABUL SÜREÇ

- Ürün sahibi (Product Owner) onayı gerekli mi
- UAT kim yapacak
- Üretim yayını öncesi eğitim ihtiyacı

10. RİSKLER VE BAĞIMLILIKLAR

- Teknik riskler
- Zaman riskler
- Dış bağımlılıklar (SMS sağlayıcı, e-posta servisi)
- Azaltma önerileri

ÖRNEK UYGULAMA:

Başlık: "Mobil uygulamada parola sıfırlama"

HİKAYE:
"Mobil uygulama kullanıcısı olarak
Parolamı unutursam mobil uygulamadan şifre sıfırlama talebinde bulunabilmek istiyorum
çünkü masaüstü tarayıcıya gitmek zahmetli ve zaman alıcı."

KABUL KRITERLERI:
[3-5 Given-When-Then senaryosu]

TEKNIK:
- Mevcut web API endpoint'i kullanılacak
- Mobil UI'da yeni bir "Şifremi Unuttum" ekranı
- iOS ve Android aynı işlevi destekleyecek

KAPSAM DIŞI:
- Biometrik doğrulama (ayrı hikayede)
- SMS ile sıfırlama (ayrı hikayede)

Türkçe. Agile/Scrum best practice'lerine uygun.

📝 Örnek Çıktı