Kullanıcı hikâyesi (user story) nedir, nasıl yazılır?
Kullanıcı hikâyesi nedir, nasıl yazılır? Rol, amaç ve fayda kalıbı, kabul kriterleri, INVEST kontrol listesi, örnek hikâye ve gereksinimden farkı.
Kullanıcı hikâyesi nedir?
Kullanıcı hikâyesi (user story), bir ürün özelliğini onu kullanacak kişinin bakış açısından, kim olduğunu, ne istediğini ve bunu neden istediğini anlatan kısa bir ihtiyaç tanımıdır. Çevik ekipler işi kullanıcı hikâyeleri biçiminde küçük, değer üreten parçalara böler ve bu hikâyeler product backlog'unda sıralanır.
Agile Alliance'ın tanımına göre kullanıcı hikâyesi yalnızca bir yazılı not değildir; ekibin, ürün sahibinin ve kullanıcıların o ihtiyaç hakkında konuşarak edindiği bilginin tamamını kapsar. Kavram Extreme Programming (XP) içinde ortaya çıkmış, sonra Scrum gibi çerçevelerde yaygın olarak kullanılmaya başlamıştır.
Kullanıcı hikâyesi nasıl yazılır?
En yaygın kalıp rol, özellik ve fayda üçlüsüdür:
"Bir [rol] olarak, [ne yapmak] istiyorum, böylece [fayda]."
Kalıbın üç parçası farklı soruları yanıtlar. Rol, ihtiyacın kime ait olduğunu; özellik, kullanıcının ne yapabilmesi gerektiğini; fayda ise bunun neden değerli olduğunu söyler. Fayda kısmı en sık atlanan bölümdür ama önceliklendirme ve alternatif çözüm arayışı için en çok işe yarayan kısımdır.
Agile Alliance'ın andığı kart, konuşma ve onay (card, conversation, confirmation) modeli bu yapıyı tamamlar: kart hikâyeyi hatırlatır, konuşma ayrıntıyı netleştirir, onay ise kabul kriterleriyle hikâyenin ne zaman tamamlanmış sayılacağını belirler.
Örnek hikâye ve kabul kriterleri
Bir online eğitim platformu için örnek:
"Bir öğrenci olarak, yarım bıraktığım dersi kaldığım yerden açabilmek istiyorum, böylece videonun başını tekrar izlemek zorunda kalmam."
Kabul kriterleri, hikâyenin test edilebilir koşullarıdır ve sık kullanılan biçim "Verilen, Olduğunda, O halde" (Given, When, Then) kalıbıdır:
- Verilen: öğrenci bir videoyu yarıda kapatmış. Olduğunda: aynı derse geri dönüyor. O halde: video kaldığı saniyeden başlıyor.
- Verilen: öğrenci videoyu sonuna kadar izlemiş. Olduğunda: derse geri dönüyor. O halde: video baştan başlıyor ve ders tamamlandı olarak işaretli kalıyor.
- Verilen: öğrenci başka bir cihazdan giriş yapmış. Olduğunda: aynı dersi açıyor. O halde: kaldığı yer o cihazda da geçerli.
İyi bir hikâyenin ölçütleri: INVEST
Agile Alliance'ın da andığı INVEST kontrol listesi, hikâyenin geliştirmeye hazır olup olmadığını sınamak için kullanılır:
- Independent (bağımsız): başka hikâyelere sıkı bağımlı değil.
- Negotiable (konuşulabilir): ayrıntılar sözleşme gibi dondurulmamış.
- Valuable (değerli): kullanıcıya ya da işe görünür bir değer sağlıyor.
- Estimable (tahmin edilebilir): ekip büyüklüğünü kestirebiliyor.
- Small (küçük): bir sprint içinde bitirilebilecek boyutta.
- Testable (test edilebilir): kabul kriterleriyle doğrulanabiliyor.
Bir sprinte sığmayacak kadar büyük hikâyelere epik (epic) denir; epikler geliştirmeden önce daha küçük hikâyelere bölünür.
Kullanıcı hikâyesi ile gereksinim ve kullanım senaryosu farkı
Geleneksel gereksinim dokümanı "Sistem şunu yapmalıdır" diye sistemi anlatır; kullanıcı hikâyesi ise kullanıcının hedefini anlatır ve ayrıntıyı konuşmaya bırakır. Bu yüzden hikâye tek başına eksiksiz bir şartname değildir, ekip içi diyaloğun başlangıç noktasıdır.
Kullanım senaryosu (use case) ise kullanıcı ile sistem arasındaki etkileşimi adım adım, ana ve alternatif akışlarıyla tanımlar. Hikâye daha kısadır ve önceliklendirmeye uygundur; karmaşık akışlarda ikisi birlikte kullanılabilir.
Sık yapılan hatalar
Kalıba uygun yazılmış hikâyeler bile şu nedenlerle işe yaramaz hale gelebilir:
- Rol olarak "kullanıcı" yazmak: hangi kullanıcı olduğu belirsiz kalır.
- Teknik görevi hikâye kılığına sokmak ("Bir geliştirici olarak veritabanı tablosu istiyorum").
- Fayda kısmını boş geçmek ya da özelliği tekrar etmek.
- Kabul kriteri yazmadan geliştirmeye başlamak; tamamlandı tartışması sprint sonunda çıkar.
Kullanıcı hikâyesini Mindset programlarında nerede çalışırsınız?
Yapay Zeka Destekli İş Analistliği Sertifika Programı'nda "Çevik Ortamda İş Analizi ve Kullanıcı Hikayeleri" modülü doğrudan bu konuya ayrılmıştır. PSPO I Product Owner Hazırlık programında "Ürün Birikimi ve Önceliklendirme" modülü hikâyelerin backlog içinde yönetimini ele alır.
Hikâyeleri bir araçta takip etmek için Jira ile Proje Yönetimi Eğitimi'ndeki "Issue Takibi, Backlog Yönetimi ve Sprint Planlama" modülü uygundur.
İlgili Mindset programı
Yapay Zeka Destekli İş Analistliği Sertifika Programı
Sık sorulan sorular
Kullanıcı hikâyesini kim yazar?
Backlog'un sahibi olan Product Owner hikâyelerden sorumludur, ama hikâyeleri tek başına yazmak zorunda değildir. İş analistleri, geliştiriciler, tasarımcılar ve paydaşlar da hikâye önerebilir. Önemli olan hikâyenin ekiple birlikte konuşularak netleşmesi ve kabul kriterlerinin geliştirme başlamadan üzerinde anlaşılmasıdır. Hikâyeyi kimin yazdığından çok, kimin anladığı önemlidir.
Kullanıcı hikâyesi ile görev (task) arasındaki fark nedir?
Hikâye, kullanıcıya değer sağlayan bir sonucu anlatır. Görev ise o sonuca ulaşmak için ekibin yapacağı teknik iştir: arayüz tasarımı, servis geliştirme, test yazma gibi. Bir hikâye genellikle sprint planlamasında birkaç göreve bölünür; görevler tek başına kullanıcıya bir şey teslim etmez.
Kullanıcı hikâyeleri nasıl tahmin edilir?
Çevik ekipler hikâyeleri saat yerine çoğunlukla göreceli büyüklükle tahmin eder; hikâye puanı ya da tişört bedenleri bu amaçla kullanılır. Ekip, iyi bildiği bir referans hikâyeyi seçip diğerlerini ona göre büyük ya da küçük olarak değerlendirir. Tahmin edilemeyen hikâye genellikle belirsiz ya da fazla büyüktür ve bölünmelidir.
Teknik işler kullanıcı hikâyesi olarak yazılmalı mı?
Her işin hikâye kalıbına sokulması gerekmez. Altyapı yenileme ya da teknik borç gibi işler, kullanıcıya dolaylı faydası açıkça yazılabiliyorsa hikâye olarak, yazılamıyorsa ayrı bir iş öğesi olarak backlog'a eklenir. Kalıbı zorlamak yerine işin neden gerektiğini anlaşılır biçimde yazmak daha değerlidir.
İlgili rehberler
İlgili eğitimler
Kategori: İş Analizi ve Süreç Yönetimi, Proje Yönetimi ve Çeviklik