Scrumda User Story nedir? Nasıl iyileştirilebilir?

Agile proje yönetim metotlarından olan Scrum, projeyi küçük parçalara ayırarak yönetmeyi önerir. Bu küçük parçalar “User Story” başlığı altında ele alınır.

Genel çerçeveden bakıldığında Scrum’ da User Story kullanıcının yazılım, ürün veya hizmet ile etkileşimi arttırmayı hedefleyen metinler olarak özetlenebilir.

Yani, bir ürün geliştirilirken user story’ler olmazsa olmazdır diyebiliriz. Bu sebeple, user story oluşturulmadan evvel, son kullanıcının talebini net olarak karşılanarak memnuniyet sağlanabilmesi için öncelikle Ürün Ekibi tarafından isterlerin netleştirilmesi gerekmektedir.

Ürün ekibi tarafından toplanan isterler, son kullanıcıya fayda sağlamanın yanında ürün geliştirilmesinde de maksimum fayda sağlayacak şekilde önceliklendirerek proje ekibi ile paylaşılır.

Proje ekibi, bu talepleri “User Story” aracılığı ile Yazılım Geliştirme ekibi ile paylaşmaktadır. Birçok kaynakta da yer aldığı gibi iyi bir “User Story” nin altı temel değer vardır.
Bunlar: Bağımsız (Indepented), tartışılabilir (Negotiable), değerli( Valuable), tahmin edilebilir (Estimatable), küçük (Small) ve test edilebilir (Testable) olması. (INVEST Modeli)

Bir user story’nin bir başka user storye bağımlılığının olmaması veya az olması proje planlamasını kolaylaştıracaktır. Bir user story, eforlandırma aşamasına gelene kadar Ürün-Proje-Yazılım Geliştirme ekibi içerisinde tartışılabilir; eforlanana kadar değiştirilebilir. Tartışmaların genel çerçevesi, son kullanıcının maksimum faydasını sağlayabilmek başta olmak üzere, ürünün bütünlüğünü korumak teknik alt yapıya uyum sağlamak aynı zamanda performans etkilenmeden ürünü geliştirmeyi hedeflemek yönünde bütüncül bir amaç ile son kullanıcı ve müşteriye değer sağlamak yönünde çıktıya ulaşabilmeye yöneliktir.

User story’lerin küçük olması ise anlaşılabilirliği; eforlandırılmayı kolay ve gerçekçi belirleyebilmek anlamında önem teşkil etmektedir. Birbirini tamamlayan nitelikteki bu zincirlerin son değeri ise test edilebilir olmasıdır. Kabul kriterleri belirli olan user storylerin, testi çok daha kolay gerçekleşebilmek ile beraber son kullanıcı tarafından onaylanabilmesini de kolaylıkla sağlayacaktır.

Peki, bu User Story’leri kim oluşturabilir?

Deneyimler ile değerlendirildiğinde, bu metodolojiyi benimseyen şirketlerde user storyler proje geliştirme ekibinde herkes tarafından oluşturulabilir. Fakat, ideal olan öncelikle iş analistleri tarafından temel değerlere sadık kalarak user story’lerin oluşturulmasıdır.

Yeterli bir zamana sahip olan iş analisti, bu altı değere sahip çıkarak user storyleri detaylandırabilir. Refinement gözlemleri ile “Daha iyi nasıl olabilir?” mantığı ile user storyleri iyileştirebilir.

Her iş analistinin refinementlarda kolaylıkla anlaşılan ve eforlanan user story’leri olmak ile beraber; aynı zamanda reddedilen ; anlaşılmayan veya kolaylıkla eforlandırılamayan; eforlandırılsa da günün sonunda eforun dışına çıkılması zorunlu olan user storyleri olabilir.

Aslında her ikisini de yazan aynı analisttir fakat aradaki farkı oluşturan bir sürü etken olabilir. İsterin faydası tam anlaşılmamış veya aktarılamamış olabilir; user story gerektiği kadar küçük parçalara ayrılmamış basit bir dil kullanılmamış olabilir; etki alanları çıkarılamamış olabilir gibi birçok sebebi ile beraber, hepsi mevcut olsa da refinementa yetiştirmek için yeterli bir zaman olmaması durumunda analist istediği gibi bir user storyi çıkaramamış olabilir. Bu sebeple -bir iş analisti olarak da belki taraflı değerlendireceğim ama — analistin öncelikle yeterli bir zamanı mevcut olması gerekmektedir. 😊

Elbette ki sadece zamanın olması mükemmel bir user story çıkarmaya yeterli olmayabilir. Peki daha iyi user story nasıl olabilir?

Öncelikle içerik/açıklama anlamda nasıl iyileştirilebilir üzerine odaklanalım:

Bu aşamada, temel bilgi ve yeterli zamanın ötesine de geçerek, analistin deneyim sonra öz eleştirisi ile beraber eforlandırma & geliştirme işlemini gerçekleştirecek yazılım geliştirme ekibinin değerlendirmelerine önem vermesi tavsiye edilir.

Analist, refinementta eforlandırılamayarak bölünmesi talep edilen; anlaşılması zor olan storyler ile kolaylıkla anlaşılan ve eforlandırılan storyler karşılaştırarak ders çıkarabilir; aldığı dersler ile gelecek user storylerini şekillendirmeye özen gösterebilir.

Talepleri son kullanıcı ağzından sadeleştirerek, talebinin doğrudan yansıtılması sağlanabilir. Böylece user storynin hangi amaca yönelik olduğunun şeffafça özümsenmesini sağlanabilir.

Yazılım geliştirme ekibi tarafından önem verilen, işlerini kolaylaştıracak parametrelerin bilgisi alınabilir. Gelecek user story metinleri öneriler göz önüne alınarak yazabilir.

Bir rapor veya menü gibi somut çıktı görmeyi bekleyen analist, geliştirme sonrası beklenen sayfanın varsa tasarımını yoksa beklenen kaba-taslak çizimini ekleyerek, beklentinin görsel canlanmasına yardımcı olabilir.

Mevcut kurguyu ve geliştirme sonrası bekleneni user storyde paylaşarak; talebin fayda sağlayacak yanlarını vurgulayabilir. Böylece kolaylıkla karşılaştırılabilmesi sağlanabilir.

Sektördeki rakip firmalardaki benzer deneyimleri test ederek talebe yönelik olabilirliği veya farkı ortaya çıkarabilir; bu yönde user story geliştirebilir.

Son kullanıcının kullanmayı hedeflediği süreci bütün olarak artısı ve eksisi ile değerlendirmelidir. Örneğin; Bir onay akışlı bir iş gerçekleştirilecekse aynı zamanda red akışı da ayrı bir story olarak detaylandırılması gerekir.

Sadece metin değil görseller ile user story’i zenginleştirilebilir. Anlık gerçekleşen; anlatılması zor olan senaryolarda video kayıtları aracılıyla talebin daha net anlaşılmasına destek sağlanabilir.

IT ekibi içerisinde ortak bir şablon belirlenip; şablon çerçevesinde user story yazılabilir.

User story içeriğindeki geliştirmeye konu olan iş analizinin teknik analiz ile detaylandırılabilir. Burada iş analistlerini destekleyecek teknik analistlerin de rolü önem teşkil etmektedir. Teknik analiz ile detaylandırılan user story’ler yazılım terminolojisi ile beraber daha net anlaşılmasını sağlayacak; verilecek eforu kısaltacaktır.

Dikkat edilmesi gereken noktalar, kabul kriterleri altına eklenebilir canlı çıkış işlemleri yapılmadan evvel test ekibinin dikkatine sunulabilir.

Gerçekleşen veya gerçekleşebilecek hatalar ön görüde mevcut ise, konuya sadık kalarak bu hususa da ışık tutulabilir.

Bir User story’de içerik dışında iyileştirebileceğimiz alanlar da mevcut:

Öncelikle her user story için geçerli olacak herkes tarafından anlaşılacak State(Durum) larının belirlenmesi gerekmektedir ve bu statelerin her kaynağın kendi sorumluluğundaki aşamada güncel tutması gerekmektedir. Böylece hangi işin hangi durumda olduğuna dair gerçekçi bir fikre sahip olunabilir.

Gerçekleşecek iş veya etki alanları ile daha evvel ilgilenmiş bir kaynak pair atanabilir. Böylece ataması yapılan yeni kaynak gerektiğinde destek alabileceği o konudaki deneyimli kaynağa hızlıca ulaşabilir.

Genel tagler belirlenebilir ve benzer durumlarda hangi işlerin yapıldığı tagler aracılığıyla hızlıca bulunabilir; raporlanabilir. Çünkü bazı user story başlıkları benzer durumu yakalamak için yeterli olmayabilir.

Buraya kadar bahsettiğim alanlar, analistin, yazılım geliştirme uzmanının, Scrum Master’ıı destekleyecek durumlar da olsa günün sonunda nihai hedef, başta da belirttiğim üzere son kullanıcının yazılım ürün veya hizmet ile etkileşimini sağlamak; kullandığı veya kullanmak istediği özellikleri maksimum fayda ile değere ulaştırmak içindir.

Her farklı deneyim ile daha iyi user storylere ulaşmak mümkün olacaktır.

Zamanınızı ayırdığınız için teşekkür eder; “Daha iyi user story nasıl olabilir?” sorusu altında tecrübelerini paylaşacak her paydaşa da ayrıca şimdiden teşekkür ederim.