Scrum Kılavuzu | 20. YATIRIM – En iyi Kullanıcı Hikayesini Yaratmak

Yayınlanan: 2022-05-21

INVEST, iyi Kullanıcı Hikayeleri oluşturmak için bir yöntemdir. Düzgün formüle edilmiş içeriğe sahip olup olmadıklarını ve Ürünün ticari değeriyle ilgili olup olmadıklarını kontrol etmeyi sağlar. Ayrıca boyutlarının ve kullanılabilirliklerinin doğru seçilmiş olup olmadığı.

INVEST ile en iyi Kullanıcı Hikayesini oluşturma – içindekiler tablosu:

  1. giriiş
  2. Ben Bağımsız için
  3. Pazarlık için N
  4. Değerli veya Dikey için V
  5. Tahmini için E
  6. Küçük için S
  7. Test Edilebilir için T
  8. Özet

giriiş

INVEST , Bill Wake tarafından 2003 yılında oluşturulmuş bir kısaltmadır. Her harf, iyi bir Kullanıcı Hikayesini karakterize eden bir kelimenin başlangıcını temsil eder. INVEST ilkesine göre, her Kullanıcı Hikayesi şöyle olmalıdır:

  • Bağımsız
  • Pazarlık edilebilir
  • Değerli
  • tahmin edilebilir
  • Küçük
  • test edilebilir

Kullanıcı Hikayesinin ne olduğu hakkında daha fazla bilgiyi ayrı bir makalede yazdık. Burada yalnızca, erişilebilir bir dilde yazılmış yeni bir Ürün işlevselliğinin kısa bir açıklaması olduğunu belirteceğiz.

Creating the best User Story with INVEST

Ben Bağımsız için

İyi bir Kullanıcı Hikayesinin ilk özelliği bağımsız olmasıdır. Bu, açıklamasının ve özelliklerinin , diğer Kullanıcı Hikayelerine atıfta bulunulmadan anlaşılabilir olması gerektiği anlamına gelir. Ama hepsinden önemlisi, gerçekleşmesi diğer Kullanıcı Hikayeleri ile ilişkilendirilmemelidir. Tabii ki, tam bağımsızlık olmayacak. Ürün oluşturmayı tamamen ayrı modüllere bölemezsiniz. Ancak, Kullanıcı Hikayelerini olabildiğince bağımsız tutmayı hatırlamak çok önemlidir. Bu sayede bir tanesi uygulama aşamasına girmese veya önemli ölçüde değiştirilse bile geri kalanın değiştirilmesi gerekmeyecektir. Kural olarak, Kullanıcı Hikayesi ayrı ve tutarlı bir bütün oluşturmalıdır.

Pazarlık için N

Kullanıcı Hikayesi tartışılabilir olmalıdır. Bu, oraya ulaşmanın yolunu değil, Hedefi belirlediği anlamına gelir.

Başka bir deyişle, uygulanacak teknik bir çözümü değil , Ürünün beklenen bir özelliğini tanımlar.

Kullanıcı Hikayesi görüşmesi Ürün Sahibi ve Geliştirme Ekibi arasında gerçekleşir. Ürün Sahibi, Ürünün belirli işlevlerinin uygulanmasını önerir, yani “Ne yapılması gerektiğini” söyler. Geliştiriciler, “Nasıl” sorusunu yanıtlamaktan sorumludur. Yani, Kullanıcı Hikayesinde sunulan sorunu çözmenin belirli yollarını müzakere etmek.

Değerli veya Dikey için V

INVEST kısaltmasında, V harfi iki niteliği temsil eder:

  • Değerli
  • Dikey

Her ikisi de iyi bir Kullanıcı Hikayesinin temel özelliklerini ortaya çıkarır. Bu nedenle, her birinin ne anlama geldiğini açıklamaya karar verdik.

Değerli

Değerli bir Kullanıcı Hikayesi , değişikliğin iş amacını doğrular. Başka bir deyişle, değişikliğin neden getirileceği ve paydaşların bakış açısından neden önemli olduğu sorusuna doğru cevap verir.

Dikey

İkinci özellik; Dikey, Çevik metodolojiden türemiştir. Dikey Kullanıcı Hikayesi , Ürünün Kullanıcı tarafından görülebilen yeni bir özelliğini içerir. Yani, Ürünün seçilen bir katmanında yatay "performans iyileştirmesine" odaklanmaz. Aksine ona bir “katman” daha ekler.

Başka bir deyişle, Kullanıcı Hikayesi, tam olarak ne iyileştirilmeli? Ayrıca, Ürünün her bir işlevselliğinin mevcut çözümler üzerine inşa edildiği anlamına gelir.

Tahmini için E

İyi bir Kullanıcı Hikayesi tahmin edilebilir olmalıdır. Bu , Kullanıcı Hikayesinin tamamlanmış sayılabilmesi için üründe yapılacak değişikliklerin kapsamını açıkça tanımlaması gerektiği anlamına gelir. Bu, Geliştirme Ekibinin onu tamamlamak için gereken zaman ve çabayı belirlemesine olanak tanır.

Bir görevin kapsamı ve zorluğu genellikle Öykü Puanları adı verilen birimlerde tahmin edilir. Onlar akrabadır. Ve her Geliştirme Ekibi, önceki deneyimlere dayanarak pratikte Story Point değerini hesaplar.

Ayrı makalelerde, Geliştirme Ekibi Hızı ve bunun nasıl ölçüleceği hakkında daha fazla bilgi verdik.

user story

Küçük için S

Geliştirme Ekibi tarafından gerçekleştirilmek üzere kabul edilen Kullanıcı Hikayesi kısa ve öz olmalıdır. Yani, bir Sprint'ten daha uzun olmamalıdır. Geliştiriciler, Sprint Planning sırasında Ürün Sahibi tarafından önerilen Kullanıcı Hikayesinin çok uzun olduğunu keşfederse, bunu muhtemelen bağımsız bölümlere ayırmaları gerekir.

Test Edilebilir için T

INVEST kısaltmasının son harfi test edilebilir anlamına gelir. Bu, Kullanıcı Hikayesinde açıklanan Ürün değişikliğinin su içermesi ve doğrulanabilir olması gerektiği anlamına gelir. Başka bir deyişle, Geliştiriciler tarafından uygulanan çözümün varsayılan değeri belirli bir Paydaş'a teslim edip etmediğini doğrulamak mümkün olmalıdır.

En iyi Kullanıcı Hikayesini Oluşturma – özet

INVEST, iyi yazılmış bir Kullanıcı Hikayesini tanımlayan bir kısaltmadır. Olmalı:

  1. Diğer Kullanıcı Hikayelerinden Bağımsızdır . Gerektiğinde değiştirilebilmesi veya Ürün İş Listesinden çıkarılabilmesi için.
  2. Pazarlık edilebilir. Nasıl yapılacağının seçimini Geliştiricilere bırakarak ne yapacağını belirtmelidir.
  3. Değerli , yani Ürünü değiştirmenin iş anlayışını haklı çıkarmak. Veya Dikey, yani Ürün'ün Kullanıcı tarafından görülebilen yeni bir özelliğinin sunulması.
  4. Tahmin edilebilir , yani tanımlanabilir bir boyuta ve tamamlama kriterine sahip olmak.
  5. Bir Sprint'te tamamlanacak kadar küçük .
  6. Uygulandığının kesin olarak belirlenebilmesi için test edilebilir.

İçeriğimizi beğendiyseniz, Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest'teki meşgul arılar topluluğumuza katılın.

Scrum Guide | 20. INVEST - Creating the best User Story caroline becker avatar 1background

Yazar: Caroline Becker

Bir Proje Yöneticisi olarak Caroline, en iyi iş akışlarını tasarlamak ve süreçleri optimize etmek için yeni yöntemler bulma konusunda uzmandır. Organizasyonel becerileri ve zaman baskısı altında çalışabilme yeteneği, onu karmaşık projeleri gerçeğe dönüştürmek için en iyi kişi yapıyor.

Tüm gönderileri görüntüle

Scrum Kılavuzu:

  1. Temel terimler, roller ve kavramlar sözlüğü
  2. Scrum nedir?
  3. Scrum değerleri
  4. Şirketinizde Scrum nasıl uygulanır?
  5. Scrum Takımı - nedir ve nasıl çalışır?
  6. Ürün Sahibi kimdir?
  7. Ürün Sahibinin En Sık Yapılan Hataları
  8. Scrum Master kimdir?
  9. İyi bir Scrum Master'ın Özellikleri
  10. Scrum Master'ın en yaygın hataları
  11. Scrum Master hangi istatistikleri ve metrikleri izlemelidir?
  12. Ürün Sahibi ve Scrum Master Arasındaki İşbirliği
  13. Scrum'da Geliştirme Takımı
  14. Geliştiricilerin en yaygın hataları
  15. Scrum eserleri
  16. Scrum'ı Ölçeklendirme
  17. Sprint İş Listesi
  18. Ürün İş Listesi nedir?
  19. Kullanıcı Hikayeleri nedir?
  20. INVEST ile en iyi Kullanıcı Hikayesini Oluşturmak
  21. En yaygın Kullanıcı Hikayesi hataları
  22. Kullanıcı Hikayesi Kabul Kriterleri
  23. Scrum'da Tahmin ve Öykü Puanları
  24. Poker Planlama
  25. Takım Tahmin Oyunu
  26. Artış Tanımlama
  27. Scrum etkinlikleri
  28. Scrum'da Sprint nedir?
  29. Scrum Takımı Taahhütleri - Ürün Hedefi, Sprint Hedefi ve Tamamlamanın Tanımı
  30. Burndown Grafiği nedir?
  31. İş bitim grafiği nasıl oluşturulur ve yorumlanır?
  32. İş bitim grafiğinin avantajları ve dezavantajları
  33. Scrum ve Scrumban'da Kanban panoları
  34. Scrum'da Hız - Geliştirme Takımının Hızı
  35. Günlük Scrum
  36. Sprint Planlama
  37. Sprint İncelemesi
  38. Sprint Retrospektifi nedir?
  39. Sprint Retrospektifi sırasında yaygın hatalar
  40. Ürün İş Listesi beslemesi