Scrum: Bir sprint'ten daha uzun olan backlog maddeleri nasıl kullanılır?

SCRUM ile başlıyorum ve bir şeyi anlamada sorun yaşıyorum. SCRUM, bir sprint'ten daha uzun süren birikim kalemlerini nasıl işler?

Bu tür öğeler Epic olarak adlandırılır ve tek bir sprintten daha kısa olan ve bu nedenle planlanabilen daha küçük kullanıcı hikayelerine veya Epiklere ve bunlar da ortak hikayelere bölünecek olan Temaya bölünmelidir. Destanlar ve Temalar ana karakteristiği paylaşır - yüksek belirsizlik düzeyi = uygun bir şekilde tahmin edilemezler (tahminler genellikle çok yüksektir ve bu nedenle tek bir koşuya uymazlar).

Bu nedenle, bu tür hikayelerle başlamak iyidir, ancak ürün sahibi onları daha küçük özel hikayelere bölmeden bunları planlayamazsınız. Bu hikayeler yalnızca bazı daha büyük istenen özellikleri (Epic) veya tüm özellik setlerini (Tema) not almak için kullanılır. Bu hikayeleri kırmak özelliği özel kılacaktır.

Ayrıca ürün biriktirme listesinin Iceberg yapısını izler.

Böyle öğelerin yok. Eğer varsa, o zaman biriktirme öğesi yeterince spesifik değildir ve daha küçük öğelere uygun şekilde ayrılmamıştır. Bazı kimseler , bunlara "backlog" değil " fatlog" ve "Scrum" da anti-kalıp olarak kabul edilir.

Pasta benzetmesi kullanıcı hikayesi: Bir pasta yiyen kişi olarak öğleden sonra pasta yemek istiyorum. Bir öğleden sonra bir bütün pastayı yiyemem, bu yüzden yiyebileceğim miktarda sığması gerekiyor.

Scrum ilk "icat" edildiğinde, varsayılan sprint normalde 4 haftaydı.

Bana söylenenlere göre, çok uzun süren sprint büyüklüğünün sebebi, o zamanlar insanların kısa sprintlerde her şeyi başarabileceğinizi hayal etmekte zorlandıklarıydı.

Ekipler daha fazla titizlik kazandıkça, backlog ürünlerini daha kolay yönetilebilir büyüklükteki daha küçük öğelere nasıl daha iyi ayırabileceklerini öğrendiler ve geliştirme ekipleri ön tasarımın abartılmamasını, ancak yeterince yapılmasını sağladı.

Bugün, çoğu takımın sprint süresinin 4 hafta olacağını düşünüyor. 2 haftanın oldukça normal olduğu izlenimindeyim. XP ekipleri yalnızca 1 haftalık yineleme yapar ve her yinelemede kullanıcı hikayelerinin tamamını tamamlar.

Bu nedenle, biriktirme kalemlerini daha küçük öğelere bölme konusunda daha iyi olmanız gerekir, böylece her biri nihai üründe işletme değeri bakımından küçük bir artış sağlar. Bu kanıtlanmış oldu, mümkün. (Yine de, zor olacağı çok özel alanların olabileceğini ekarte etmeyeceğim)

Bugünlerde 4 hafta boyunca uzun bir sprint olmaya katılıyorum. Geri bildirim döngüsünü azaltmak ve küçük iş birimlerini daha kısa aralıklarla döndürmek konusunda daha iyi olmak istiyorsunuz. Bu şekilde yanlış giden daha az, daha az değişecek ve bir seferde daha az karmaşıklık olacaktır.

Öyküleri bölmek çoğu zaman insanlar için sıkıntı yaratan bir alandır, ancak onunla daha da iyi olursunuz. Aşamalar halinde sunabilir ve sprint'te yine de değer sunabiliyorsanız, PO ile yakın çalışın.

İşte hikayeleri bölmeye yardım eden harika bir poster, agileforall.com adlı bir web sitesinden ve posteri burada bulabilirsiniz.

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Ayrıca, ayrıntılandırmayı ve planlamayı yaparken kısa bir süratte bir şeyi tamamlamayı taahhüt ederken bunu aklınızda tutabilmeniz için yapılan tanımınızın kullanılabilir olması da iyidir.