# User Story Writer > Bir özellik/istek tanımını, INVEST ve 3C prensiplerine uygun kullanıcı hikayelerine ve kabul kriterlerine (Çözüm Gereksinimleri) dönüştürür. Kabul kriterlerinde Fonksiyonel Gereksinimleri numaralı Ana/Alternatif/İstisnai Senaryo olarak, ayrıca Fonksiyonel Olmayan Gereksinimler (NFR) ve İş Kuralları (BR) olarak üretir; büyük hikayeleri parçalama teknikleriyle böler. Kullanıcı; "user story", "kullanıcı hikayesi", "backlog maddesi", "kabul kriteri", "acceptance criteria", "ana/alternatif/istisnai senaryo", "given when then", "çözüm gereksinimi", "NFR", "iş kuralı", "gereksinimi hikayeye çevir", "epic'i böl/parçala" gibi bir şey istediğinde MUTLAKA bu skill'i kullan — kişi açıkça "user story yaz" demese bile, bir talebi analiz edilebilir bir backlog maddesine dönüştürme niyeti varsa devreye gir. - Skill: `tolgademirli/user-story-writer` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tolgademirli/user-story-writer` - Raw SKILL.md: https://api.skillmd.com/api/skills/tolgademirli/user-story-writer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: tolgademirli (https://skillmd.com/u/tolgademirli) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tolgademirli/user-story-writer --- # Kullanıcı Hikayesi ve Kabul Kriteri Yazarı Ham bir özellik isteğini (paydaş cümlesi, e-posta, toplantı notu, epic tanımı) takıma hazır bir backlog maddesine dönüştürür: INVEST'e uygun kullanıcı hikayesi + Fonksiyonel Gereksinimler (Ana/Alternatif/İstisnai Senaryo) + Fonksiyonel Olmayan Gereksinimler (NFR) + İş Kuralları (BR). ## Gereksinim Bağlamı (önce hangi katmandayız?) - **İş Gereksinimi** — NEDEN (değişimin hedefi/sonucu) - **Kullanıcı Gereksinimi** — KİM? NE? (kullanıcı hikayesi bu katmandadır) - **Çözüm Gereksinimi** — NASIL? (kabul kriterleri = FR + NFR + BR bu katmandadır) - **Geçiş Gereksinimi** — TEKNİK OLARAK NASIL? Kullanıcı hikayesi = "Kullanıcı Gereksinimi"; kabul kriteri = "Çözüm Gereksinimi". Hikaye değeri anlatır; kabul kriteri o değerin nasıl doğrulanacağını anlatır. ## Çalışma Prensibi 1. Girdiden **KİM (aktör)**, **NE (eylem)**, **NEDEN (değer)** üçlüsünü çıkar. Eksikse varsayımını açıkça belirt ama uydurma; belirsizlik **Açık Sorular**a yazılır. 2. Hikayeyi INVEST'e göre kontrol et; büyükse parçala. Detaylı INVEST tanımları ve 3C kuralı için `references/invest-ve-3c.md` dosyasını oku. 3. Fonksiyonel Gereksinimleri **numaralı Ana/Alternatif/İstisnai Senaryo** olarak yaz (aşağıdaki kurallara uy). NFR ve İş Kurallarını ayrı bölümlerde ver. Tam yapı, kategoriler ve Given/When/Then alternatifi için `references/kabul-kriteri-rehberi.md` dosyasını oku. 4. Hikaye tek sprint'e sığmıyorsa `references/hikaye-parcalama.md` tekniklerinden uygun olanı seçip böl. ## Hikaye Formatı (HER ZAMAN bu kalıbı kullan) ``` olarak, istiyorum, böylece . ``` Kötü örnek: "Kullanıcı sisteme login olabilmelidir." → Rol yok, değer yok, test kriteri yok. İyi örnek: "TrendShop mobil kullanıcısı olarak, satın alma kararı vermeden önce farklı ürünleri yan yana karşılaştırabilmek istiyorum, böylece en uygun ürünü daha hızlı seçebilirim." ## Fonksiyonel Gereksinim Senaryoları — TANIMLAR (kritik) Fonksiyonel Gereksinimleri her zaman üç senaryo türüyle, **numaralı adımlar** hâlinde yaz: - **Ana Senaryo** — Eylemin gerçekleştiği, en çok tercih edilen (mutlu) yol. - **Alternatif Senaryo** — Eylemin yine gerçekleştiği, görece daha az tercih edilen yol. - **İstisnai Senaryo** — Eylemin bir şekilde gerçekleşmediği; hata alınan, yarıda kesilen yol. ### Alternatif senaryo numaralandırma kuralı (ZORUNLU) Alternatif senaryo, ana senaryodan **hangi adımda ayrılıyorsa o adımın numarasından** başlar ve alt-numaralandırma ile ilerler. Örn. ana senaryonun 9. adımından sonra dallanıyorsa: `9.1, 9.2, 9.3 ...`. Başlığında ayrıldığı adımı belirt: *"Alternatif Senaryo – Diğer nedeni (Ana Senaryo 9. adımdan ayrılır)"*. **Birden fazla alternatif senaryo olabilir**; her biri kendi ayrıldığı adımın numarasından başlar (ör. biri 6.1..., diğeri 9.1...). Senaryo sayısını yapay olarak tek senaryoya indirmeye çalışma; kaç gerçek dallanma varsa o kadar alternatif senaryo yaz. ## INVEST ve 3C (özet — detay reference'ta) INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Estimable/Small değilse: parçala. 3C: Card (kart, başlangıç noktası), Conversation (asıl değer burada), Confirmation (kabul kriterleriyle onay). ## CSIR Prompt Tekniği (kullanıcıya öner) AI ile en iyi sonuç: **Context** (bağlam/persona) + **Specific Information** (spesifik istek) + **Intent** (amaç) + **Response Format** (istenen çıktı formatı). Belirsiz istek gelirse kullanıcıdan bu dört parçayı netleştirmesini iste. ## Çıktı Formatı (HER ZAMAN bu şablonu kullan) ``` ### US-: **Hikaye** olarak, istiyorum, böylece . **Kabul Kriterleri** *Fonksiyonel Gereksinimler* Ana Senaryo 1. 2. (NFR 1) 3. (BR 1) ... Alternatif Senaryo – (Ana Senaryo . adımdan ayrılır) .1 .2 ... İstisnai Senaryo – 1. 2. (BR ) ... *Fonksiyonel Olmayan Gereksinimler (NFR)* - NFR 1 – () *İş Kuralları (BR)* - BR 1 – **Öncelik:** **Tahmini Boyut:** **Açık Sorular:** **Varsayımlar:** ``` Birden fazla hikaye üretilirse en sonda kısa bir **Backlog özeti** tablosu ekle (US no, başlık, öncelik, boyut). ## Kalite Kuralları - Fonksiyonel Gereksinimler her zaman Ana + (varsa) Alternatif + İstisnai Senaryo içerir. - Alternatif senaryo, ayrıldığı adımın numarasından alt-numaralandırma ile başlar (9.1, 9.2...). - İstisnai senaryo = eylemin gerçekleşmediği/hata alınan yol; her hikayede en az bir tane olsun. - NFR'leri kategoriyle etiketle (Hız/Güvenlik/Kullanılabilirlik/Uyumluluk) ve ölçülebilir yaz. - Kabul kriterleri çözümü değil gözlemlenebilir davranışı anlatmalı. - Her hikaye tek bir değer sunmalı; birden fazla değer varsa parçala. ## Kaynak Dosyaları - `references/invest-ve-3c.md` — INVEST'in detaylı tanımları + 3C kuralı. Hikaye kalitesini değerlendirirken **oku**. - `references/kabul-kriteri-rehberi.md` — Ana/Alternatif/İstisnai Senaryo kuralları, numaralandırma, NFR kategorileri, İş Kuralları ve Given/When/Then alternatifi. Kabul kriteri yazarken **oku**. - `references/hikaye-parcalama.md` — 8 hikaye parçalama tekniği. Büyük hikayeyi bölerken **oku**. - `scripts/hikaye_denetle.py` — Hikayeleri bir `.md` dosyasına kaydettikten sonra biçim/kalite denetimi için **çalıştır** (`python hikaye_denetle.py `). Kodu okuman gerekmez. - `assets/hikaye_sablonu.md` — Kullanıcı Jira'ya kopyalamak isterse temel al. - `assets/cozum_gereksinimleri_sablonu.md` — Detaylı Çözüm Gereksinimleri belgesi istenirse temel al. - `assets/backlog_import.csv` — Toplu içe aktarım isteniyorsa bu CSV başlık yapısını kullan.