30 saniyelik özet

User Story, Türkçe karşılığıyla kullanıcı hikâyesi, bir ihtiyacı kullanıcı açısından ifade eden kısa bir çalışma biçimidir. Kimin hangi işi yapmak istediğini ve bunun neden önemli olduğunu açıklar. Yaygın cümle düzeni “Bir kullanıcı olarak, şu ihtiyacı karşılamak istiyorum; böylece şu faydayı elde edebilirim” şeklindedir. Ancak cümleyi doldurmak, ihtiyacın doğrulandığını veya geliştirmeye hazır olduğunu göstermez. Hikâye; araştırma, ekip görüşmesi ve kabul beklentileriyle birlikte anlam kazanır. İyi bir hikâye, çözüm seçeneklerini konuşmayı ve beklenen davranışı değerlendirmeyi kolaylaştırır. Hikâyenin tamamlanmasıyla kullanıcının hayatında beklenen değişimin oluşması da ayrı incelenmelidir.

Neden önemli?

Bir iş maddesinde “Sistem e-posta göndersin” yazıyor. Geliştirici gönderim zamanını, tasarımcı mesaj içeriğini, ürün sahibi ise geciken siparişlerin görünmesini düşünüyor. Aynı kısa ifade, farklı kişilerde farklı çözüm beklentileri oluşturuyor.

Sorun ayrıntının azlığı kadar, ihtiyaçla çözümün birbirine karışmasıdır. E-posta gönderimi bir araç olabilir. Asıl ihtiyaç operasyon sorumlusunun müdahale gerektiren siparişleri zamanında fark etmesi olabilir. Bu amaç açıklanırsa e-postanın yanında panel uyarısı veya görev oluşturma gibi seçenekler de değerlendirilebilir.

Kullanıcı hikâyesi bu görüşme için ortak bir başlangıç sağlar. Hangi kişinin hangi koşulda neye ihtiyaç duyduğunu açıklamak, teknik çalışmayı kullanıcı göreviyle ilişkilendirir. Böylece gereksiz özelliklerin veya yanlış varsayımların daha erken tartışılması mümkün olur.

Yönetici açısından değeri, küçük işlerin yatırım gerekçesiyle bağını görebilmektir. “Bu hikâyeyi neden yapıyoruz?” sorusu yalnızca talebi kimin ilettiğiyle cevaplanmamalıdır. Hangi sorunu gidereceği, o soruna ilişkin kanıt ve beklenen fayda da açıklanabilmelidir.

Öte yandan her ihtiyacı aynı cümle kalıbına sıkıştırmak bilgi kaybı yaratabilir. Karmaşık iş kuralları, süreç çizimleri veya teknik koşullar ayrıca belgelenebilir. Kısa anlatım, gerekli bilgiyi silmek için gerekçe olmamalıdır. Bir hikâyenin okunması kolay olabilir; uygulanması için gereken ortak anlayış yine de eksik kalabilir.

Terim nedir?

Agile Alliance, kullanıcı hikâyelerini müşteri veya ürün sahibiyle birlikte ele alınan işin işlevsel parçaları olarak açıklar. Uygulanan hikâyenin ürün değerine katkı vermesi beklenir. Kısa kayıt, bu katkıyı hatırlatan ve çalışma hakkında konuşmayı destekleyen bir araçtır.

Kavram kaynağı: Agile Alliance, User Stories.

Bir hikâyede kullanıcı, ihtiyacı ve fayda arasındaki ilişki açık olmalıdır. Kullanıcıyı “herkes” diye tanımlamak çoğu zaman değerlendirmeyi zorlaştırır. Yeni başlayan hesap yöneticisiyle deneyimli operasyon uzmanının aynı ekrandaki ihtiyacı farklı olabilir. İlgili rol yeterince somut yazılmalıdır.

İhtiyaç ile fayda da birbirinin tekrarı olmamalıdır. “Rapor görmek istiyorum, böylece rapor görebileyim” ifadesi nedenini açıklamaz. Raporun hangi kararı veya görevi desteklediği araştırılmalıdır. Faydanın bulunamaması, talebin gereksiz olduğunu hemen göstermez; gerekçesinin henüz anlaşılmadığını gösterebilir.

Acceptance Criteria, yani kabul kriterleri, belirli iş maddesinin beklenen davranışını karşılamış sayılacağı koşullardır. Hikâyeyi destekler; onun yerine geçmez. Kullanıcının yalnızca kendi şirketine ait kayıtları görmesi, sonuç bulunamadığında durumun açıklanması veya belirli bir iş kuralının uygulanması bu koşullar arasında olabilir.

Teknik bir görev de kullanıcı hikâyesiyle aynı düzeyde olmayabilir. Veri tabanı alanı eklemek, bir ihtiyacı gerçekleştirmek için gereken çalışma adımı olabilir. Teknik işin önemini açıklamak için hayali bir kullanıcı rolü üretmek gerekmez. İhtiyaçla ilişki ve beklenen katkı görünür tutulmalıdır.

Gerçek vaka: GOV.UK seçmen kaydı hizmeti

GOV.UK Service Manual’ın Writing user stories rehberi, Register to vote hizmetinden somut bir kullanıcı hikâyesi örneği veriyor. Hikâye, Birleşik Krallık’ta yaşayan kişinin oy kullanabilmek için bilgilerinin seçmen kaydına alınmasını istemesi etrafında kuruluyor.

Bu anlatım, ekran veya düğme adıyla başlamıyor. Hizmeti kullanan kişiyi, yapmak istediği işi ve amacını birlikte ifade ediyor. Rehberdeki kabul beklentileri ise kullanıcının çevrimiçi kayıt yolunu, posta yoluyla başvuru formuna erişimini ve formu nereye göndereceğini bilmesiyle ilişkili.

Kaynak, hikâyeye destek olan kanıtların bağlanabileceğini ve ekip görüşmelerinde ortaya çıkan ayrıntıların kayda eklenmesini de açıklıyor. Bu, başlangıç cümlesinin bütün geliştirme bilgisini taşımak zorunda olmadığını gösteriyor.

Bu örnek resmi bir hizmet rehberinde belgelenmiş uygulamadır. Hikâye yazımının hizmetin başarısına tek başına neden olduğunu kanıtlayan bir sonuç ölçümü sunmuyor. Ürün çalışması açısından çıkarılabilecek ders, kullanıcı amacının görünür tutulmasıdır: Kayıt işlemi, kullanıcının daha geniş hedefi olan oy kullanmayla ilişkilendiriliyor.

Kaynak: GOV.UK Service Manual, Writing user stories; Register to vote örneği, son güncelleme 23 Mayıs 2016.

Varsayımsal örnek: Gönderilmeyen siparişleri fark etmek

Bir pazar yerinde operasyon sorumluları kargoya verilmemiş siparişleri farklı ekranlardan kontrol ediyor. Ürün sahibi başlangıçtaki “Gün sonunda e-posta gönderilsin” talebini araştırıyor. Görüşmelerde bazı siparişlerin teslimat taahhüdüne yaklaşmasına rağmen fark edilmediği anlaşılıyor.

Hikâye şöyle kuruluyor: Sipariş operasyon sorumlusu olarak, müdahale gerektiren ve kargoya verilmemiş siparişleri görebilmek istiyorum; böylece teslimat taahhüdü aşılmadan ilgili satıcıyla iletişime geçebilirim.

Ekip “müdahale gerektiren” ifadesini netleştiriyor. Siparişin taahhüt zamanı, iptal durumu ve kargo kaydının güncelliği değerlendiriliyor. Gerçekten gönderilmiş fakat bilgisi henüz güncellenmemiş siparişlerin yanlış uyarı oluşturabileceği görülüyor. Bu belirsizlik çözüm seçilmeden önce kaydediliyor.

Kabul kriterlerinde kapsamı belirleyen davranışlar açıklanıyor: Yetkili sorumlu ilgili siparişleri görebilecek, iptal edilmiş siparişler listede bulunmayacak ve kayıtların son güncellenme bilgisi anlaşılacak. Boş liste durumunun da açık biçimde gösterilmesi kararlaştırılıyor.

Ekip, önce tek bir operasyon grubunda kullanılabilecek dar bir senaryoyu ele alıyor. Panel uyarısı ve e-posta seçeneklerinin çalışma düzenine uygunluğu değerlendiriliyor. Ürün sahibi talepteki e-posta fikrini otomatik olarak nihai çözüm kabul etmiyor.

Teslimat sonrasında yalnızca uyarı sayısı izlenmiyor. Operasyonun uygun siparişlere müdahale edip edemediği, yanlış uyarıların iş yükü ve geç fark edilen siparişler de inceleniyor. Sayısal hedefler başlangıç verisi değerlendirilmeden yazılmıyor. Böylece çalışan bir uyarıyla beklenen operasyon faydası ayrı değerlendiriliyor.

Yaygın üç hata

  1. Kalıbı doldurmayı ihtiyaç doğrulaması saymak

Düzgün yazılmış cümle, varsayımı gerçek yapmaz. İhtiyacın hangi görüşmeye, gözleme veya kullanım bilgisine dayandığını kaydedin. Kanıt yoksa bunu açık soru olarak tutun. Paydaşın önerdiği çözümle kullanıcının yaşadığı problemi ayırın.

  1. Hikâyeyi ekip görüşmesinin yerine koymak

Metindeki belirsizlikler farklı kişilerce farklı yorumlanabilir. Tasarım, geliştirme ve test bakışlarını birlikte ele alın. Önemli kararları kayda geçirin; yalnızca toplantıya katılanların bildiği ayrıntılara güvenmeyin. Yeni bilgi gelirse açıklamayı güncelleyin.

  1. Teknik parçalanmayı kullanılabilir parça sanmak

Arayüzün tamamlanması, kullanıcı görevinin yapılabildiğini göstermeyebilir. Hikâyeyi değerlendirmek için bütün gerekli parçaların birlikte çalışmasını inceleyin. Daha küçük kapsam gerekiyorsa kullanıcı rolünü veya senaryoyu daraltın; gerekli kalite koşullarını kaldırmayın.

Mini uygulama / şablon

Sıradaki önemli iş maddesini aşağıdaki alanlarla gözden geçirin.

Hikâye başlığı
—
Kullanıcı veya rol
—
Yapmak istediği iş
—
Beklediği fayda
—
İhtiyacı destekleyen kanıt
—
Mevcut çalışma biçimi
—
Kapsama giren kullanım senaryosu
—
Kabul kriterleri
—
İlgili iş kuralları ve bağımlılıklar
—
Açık sorular
—
Değerlendirilecek çözüm seçenekleri
—
Teslimat sonrasında izlenecek sonuç
—

Ardından hikâyeyi ekipte farklı uzmanlıklardan kişilerle okuyun. Herkes aynı kullanıcı görevini ve kapsamı açıklayabiliyor mu? Kabul kriterleri gözlenebilir mi? Belirsizlik varsa geliştirme ayrıntılarını tahmin ederek kapatmak yerine hangi bilginin gerektiğini belirleyin. Hikâyeyi ortak anlayışın kaydı olarak kullanın.

İlgili terimler

Product Backlog, Product Owner, Acceptance Criteria, Backlog Refinement, User Story Mapping, Initiative, Epic, Task, Definition of Done, Customer Interview, Business Rule, Outcome ve Output