Kullanıcı Hikayesi (User Story), Agile yaklaşımın bir parçasıdır. Proje gereksinimlerinin kolay bir şekilde anlaşılmasına yardımcı olur. Kullanıcı hikayeleri, geleneksel yöntemlerin aksine, ürün gereksinimlerinin kullanıcı deneyimi bakış açısıyla yazılır. Odak noktasında yalnızca gereksinimi yazmak değil, insan etkileşimi de vardır.

Kullanıcı Hikayesi Nedir?

Kullanıcı hikayesi, geliştirilecek olan ürün özelliğinin, o özelliği kullanacak olan kişinin bakış açısıyla yazılan basit cümleciklerdir. Ögeleri hikayeleştirmekteki amaç, ürün özelliğinin kullanıcı ile olan etkileşimini gerçek hayattaki gibi simule etmektir. Böylece kullanıcı, ürün geliştirildiğinde hangi ürün özelliğini kullanabileceğini kolayca anlamış olacaktır.

Hikayenin yarar sağladığı kullanıcı ve hikayenin doğru bir şekilde uygulandığını belirten kabul kriterleri birlikte ifade edilerek yazılır. Genelde kullanılan standatlaşmış bir şablonu vardır.

As a role, I want function, [so that purpose]

Şablondaki “amaç (purpose)” bölümü isteğe bağlı olarak yazılır. Rol ve ürün özelliği belirtildiğinde her şey belirgin ve anlaşlıyorsa bu bölümü yazmaya gerek yoktur.

Birkaç örnek vermek gerekirse;

Örnek 1: Amaç belirterek yazılan bir user story

“As an end user, I want to get a report on my account activity, to check if everything is OK.”

”Son kullanıcı olarak, her şeyin yolunda olduğunu kontrol etmek için, hesap etkinliğime ilişkin bir rapor almak istiyorum.”

Örnek 2: Amaç belirtmeye gerek olmayan bir user story

“As a system administrator, I want to reset passwords.”

“Bir sistem yöneticisi olarak, şifreleri sıfırlamak istiyorum.”

Örnek 3:

“As a system administrator, I want to have an SQL database for the system.”

“Bir sistem yöneticisi olarak, sistem için bir SQL veritabanına sahip olmak istiyorum.”

Örnek 3’teki örnek UserStory’ler için yanlış bir örnektir. Kullanıcı hikayelerinin ikinci bölümü bir eylem ile ilgilidir. Yapılacak olan aksiyonu anlatmalı, sahip olunması gereken ihtiyaçları değil.

Kullanıcı Hikayesi Detaylandırma

Kullanıcı hikayeleri proje başlarında genellikle belirsizdir ve high level (yüzeysel) bilgi içerir. Bu yüzden geliştirme ekibinin tüm ayrıntılara hakim olabilmesi için kullanıcı hikayelerine detay eklenmesi gerekir. Bunun iki farklı yöntemi vardır;

1. Kullanıcı hikayesini alt hikayelere bölmek
2. Kullanıcı hikayesine kabul kriteri eklemek

Kullanıcı hikayesi detaylandırma için ilk yöntem, hikayeyi birden fazla alt hikayelere (Sub Stories) bölmektir. Yani ana hikayeyi referans alan alt hikayecikler oluşturmak gibi düşünebiliriz.

Kullanıcı Hikayesi detaylandırma için ikinci bir yol da, ürün sahibinin hikayenin sağlandığını kabul etmesi için gereken kabul kriterlerini belirlemesidir. Bu kriterleri yine ana hikayeye ekleyerek detaylandırma çalışması yapılabilir.

Bu konuyu daha derinlemesine ve örnekleriyle ele alan yazıya buradan ulaşabilirsiniz.

Kullanıcı Hikayesi Detaylandırma Yöntemleri

Kullanıcı Hikayesi’ni Kim Yazmalı?

Herkes kullanıcı hikayesi yazabilir. Her Scrum takımının çalışma şekli farklı olduğu için bu çalışmayı bir kurala bağlamak sağlıklı olmayacaktır.

Kullanıcı hikayeleri, son kullanıcı odaklı yazıldığı için bu çalışmayı paydaşlar (stakeholders) yapabilir. Ayrıca ürün sahibi süreçlere hakim olduğundan ve paydaşların isterlerini çok iyi bildiğinden, bu çalışmayı Product Owner da yapabilir. Hatta bazı scrum takımları tüm ekip bireyleri ile birlike yazabilir. Bu tamamen ekibe, projeye ve/veya çalışma kültürüne bağlı değişiklik gösterecektir.

Hikayeler yazıldığında Product Owner sorumluluğunda olan Product Backlog üzerinde toplanmaladır. Product Owner yazılan hikayelerin kalitesinden ve sıralanmasından sorumludur. Kullanıcı hikayesini her kim yazarsa yazsın, son söz yine de Product Owner’da olması yararlı olacaktır.

Kullanıcı Hikayesi Ne Zaman Yazılmalı?

Kullanıcı hikayeleri tüm proje boyunca yazılmalıdır. Agile geliştirilen bir proje için tüm hikayeleri proje başında yazıyor olmak yanlış bir çalışmadır. Gereksinim çalışmasını başta yapmak, sonradan değişiklik gösterecek olan özellikler için yapılmış çalışmaları boşa yapmak anlamındadır. Zaten çevik çalışabiliyor olmak da bu değişime ayak uydurabilmektir.

Proje süresince, Product Backlog’da birkaç sprint’i idare edecek kadar hikaye olması, proje yaşam döngüsünü döndürmeye yeterlidir. (Tabiki fazlası da olabilir.) Ayrıca yeni eklenen hikayeler high level bilgi içerebilir. Zamanla bu hikayeler detaylandırılarak geliştirmeye hazır hale getirilmelidir.

Product Backlog Refinement Teknikleri

Product Backlog Refinement nedir? Product Backlog Management nasıl yapılır? Refinement Aktiviteleri ve Refinement Teknikleri nelerdir?

Etkili Kullanıcı Hikayesi (User Story)Yazma Kılavuzu

İlkim Dilara KADAKALOĞLU