Scrum’da “User Story”‘ler kullanıcı ile sistem arasındaki etkileşimi anlatmak için kullanılan ve kullanıcının kazancını  vurgulayan metinlerdir. Bir “user story”, yazılım geliştiricinin harcayacağı eforun tahminini yapabilmesi için gereken bilgiyi içeren ve bir gereksinimden daha üst düzeyde olan tanımlamadır. “User Story”‘leri daha iyi anlamak için kendinizi müşterinin yerine koymanız gerekmektedir. User Story’ler “use case”‘ler veya senaryolardan daha küçük parçalardır ve bunları yazılımcıların kendisi değil projenin sahibi yazar.[3] Bir insanın birkaç dakika içerisinde yazabileceği kadar basit ve anlaşılabilirdirler. Fonksiyonel olmayan gereksinimleri de kapsamalıdırlar. Bir story yazıldığında ona ne kadar efor gerektiğinin tahmini yapılabilmelidir. Aksi halde amaca hizmet etmemiş olur. Efor tahmini “Story Point” denilen birimle ifade edilir. Yazılım takımı içerisinde ortalamalar alınarak bu “Story Point” zamana dönüştürülür ve bu dönüşüm sonucunda her bir story’ye zaman verilebilir. Proje sahibi tarafından her bir story’ye bir öncelik de verilmelidir. Genel pratiklerde her bir story’nin kendine özgü bir id’si olmalıdır. “User Stories Applied” [1] isimli kitabında Mike Cohn şöyle bir format önermiştir. (çalıştığım takımda da bu formatı kullanıyoruz.)

………. (rol) olarak ……… (herhangi bir şey) yapmak istiyorum böylece ……… (kazanç)

örnek:

Kütüphane görevlisi olarak kitap ismine göre arama yapmak istiyorum böylece bir kitabın bilgilerine çok çabuk ulaşabileceğim.

Öğrenci olarak kütüphane abonelik kartı almak istiyorum böylece kütüphaneden ödünç kitap alabileceğim.

İyi bir “User Story” INVEST denilen modeli kullanır.

Independent (bağımsız) : Bağımlılıklar azdır. Bu da planlamayı kolaylaştırır.

Negotiable : (tartışılabilir) Üzerinde tartışılabilir. Böylece detaylandırılabilir.

Valuable: (değerli) Müşteriye bir değer sağlar.

Estimatable: (tahmin edilebilir) Çok büyük veya anlaşılmaz olursa efor tahmini yapılamaz.

Small: (küçük) Bir haftadan daha kısa sürede takım tarafından gerçeklenebilir.

Testable: (test edilebilir) Kabul edilme kriteridir.

“User Story” yazarken en sık karşılaşılan hatalar şunlardır. Birinci hata metnin çok fazla gereksiz bilgi içermesidir. Bu durum metnin tartışılabilmesini ve “yapılacaklar listesi”nin çıkarılabilmesini zorlaştırır. Çok fazla gereksiz bilgi içermesi aynı zamanda story’nin kabul edilme kriterini içeren bilginin kaybolabilmesine neden olur. Bir takımın bir story üzerinde çalışabilmesi için öncelikle kabul edilebilme kriterini bilmesi gerekir. Bir diğer hata kabul edilebilme kriteri ile test senaryolarının birbirine karıştırılmasıdır. Kabul edilebilme kriteri şu soruya cevap verir: “Bu story’yi bitirdiğimi nasıl bileceğim?”. Test senaryoları şu sorunun cevaplarını içerisinde barındırır : “Bu story’yi nasıl test edeceğim ve test adımları nelerdir?”. Bir story üzerinde takımın çalışması sonucunda hem kabul edilme testleri (acceptance tests) hem de test senaryoları (test cases) eklenir. Peki “user story” her çalışma metodolojisi için uygulanabilir ve/veya faydalı bir metin midir? Duruma göre değişir. [2] Eğer bir takım iteratif yaklaşım uyguluyorsa (agile) o takım için “user story” veya “use case” bire birdir. Eğer o takım büyük gereksinimlerin tepeden aşağıya kadar en ince ayrıntısıyla geldiği waterfall yöntemiyle çalışıyorsa user story o takıma pek bir anlam ifade etmez.

kaynaklar:

[1] User Stories Applied: For Agile Software Development (Mike Cohn)

[2] http://www.scrumalliance.org/articles/169-new-to-user-stories

[3] http://www.agilemodeling.com/artifacts/userStory.htm