Scrum - Kısmen tamamlanmış bir Kullanıcı Öyküsünü, birikintiyi bozmadan bir sonraki Sprint'e nasıl aktarabilirim?


50

Scrum kullanıyoruz ve zaman zaman içinde planlandığı sprintte bir Kullanıcı Hikayesini tam olarak bitiremediğimizi görüyoruz. Gerçek Scrum tarzında, yazılımı yine de gönderiyoruz ve bir sonraki Sprint Planlama oturumu sırasında bir sonraki sprint'e Kullanıcı Hikayesini dahil etmeyi düşünüyoruz. Taşınmakta olduğumuz Kullanıcı Hikayesinin kısmen tamamlandığı göz önüne alındığında, bir sonraki Sprint Planlama oturumunda doğru bir şekilde nasıl tahmin ediyoruz? Dikkate aldık:

a) Sadece Kullanıcı Hikayesini tamamlamak için kalan işi yansıtmak için Öykü Noktalarının sayısını azaltmak. Ne yazık ki bu, Ürün Bekletme Listesini bildirmekle karıştırılır.

b) Kısmen tamamlanan Kullanıcı Hikayesini kapatın ve bu özelliğin kalanını uygulamak için daha az Öykü Puanına sahip olacak şekilde yenisini oluşturun. Bu, o sprintte neyi tamamlamadığımızı geriye dönük olarak görme yeteneğimizi etkileyecek ve biraz zaman alıcı görünüyor.

c) a veya b ile rahatsız etmeyin ve Sprint Planlama sırasında "Kullanıcı Hikayesinin X hikayesi puan olabilir, ama% 95'inin bittiğinden emin olduğumdan eminim" diyerek tahmin etmeye devam edin.


Yanıtlar:


12

Şu anki takımımda c).

Hız, takımın sprintte gerçekten bitirdiği şeyleri hesaba katmalıdır. Teslim edilmemiş olan bir şey müşteriye değer vermez, bu yüzden hiçbir puan saymayız, hepsi ya da hiçbiri.

Bu yüzden bitmemiş hikayeyi bir sonraki sprint'e kaydırırız ve tüm hikayeleri bir sonraki sprint hızına eklenir. Hızlar zaman içinde bile ortaya çıkar ve gelecekteki hızları tahmin etmek için referans olarak önceki birkaç sprintin ortalamasını alırız.


Ekibiniz ve durumunuz yeterince statik ise, bu seçeneğin anlamlı olduğunu görebiliyorum. Kişisel olarak bununla ilgili problemlerim var çünkü bazen bir süreç veya ortam değişikliğinin verimi olumsuz etkilediğine işaret etmek için sprint'i sprint metrikleriyle karşılaştırmam gerekiyor. Bu senin için geliyor mu?
Bill

2 sprint yan yana karşılaştırma ihtiyacı zaman zaman ortaya çıkıyor. Ancak, üretkenliği etkileyebilecek çok sayıda faktör var (yanlış tahminler, dış rahatsızlıklar…) Bitmemiş kullanıcı hikayelerini hesaba katarak bu faktörlerden sadece birini denklemden kaldırmanın gerçek nedenleri ortaya koymadığını gördük. sihirli. Bitmemiş hikayelerin neden olduğu verimlilik düşüşü, genellikle bu gibi durumlarda marjinaldir ve ölçümleri bu kadar bulanıklaştırmaz.
guillaume31

"gerçek nedenlerin sihirli bir şekilde görünmesini sağlamıyor" => ne de belirgin nedenlerin sihirli bir şekilde ortadan kaybolmasını sağlamıyorum, eklemeliyim.
guillaume31

11

Seçenek A, yaygın olarak önerilen bir eylemdir. Önceki sprint hikayesinin tamamlanması için puan vermezsiniz ve hikayeyi yeniden kopyalandığı ürün birikimine geri döndürürsünüz. Tamamlanan kullanıcı hikayelerine ve katma değere dayalı olarak hızınızı (ve diğer ölçümleri) hesaplarsınız. Bir sonraki sprint için planlama yapmaya başladığınızda, değerlerine göre en yüksek önceliğe sahip hikayeleri alırsınız (iş öncelikleri değişmişse bitmemiş hikayeyi içerebilir veya içermeyebilir). Hikayeyi tahmin ederken, öykü için yeni puanları hesaba kattığınızda zaten yapılmış olan çalışmaları ekleyin.

Elbette, alternatif bir seçenek (ve tercihim) geçmişte yaptığım bir şey olan tahmini orijinal hikaye noktalarını kullanmaktır. Bu, tahmininizin iyi ve temelli olduğunu varsayıyor, ancak sprint için çok fazla çalışma yaptınız (örneğin, hikaye aslında 3 puan değerindeydi, ancak sorun ne zaman 15 hikaye puanı düşürdüğünüzde yatıyor) sadece aşağıya çekilmeliydin 13). Tahminleri gerçekleştirme yeteneğinize güvenmiyorsanız, bu potansiyel olarak tehlikeli bir varsayımdır, ancak ekibinize ve sürecinize dayanarak işe yarayabilir.

Ancak, bunun "Ürün İş Listesinin raporlanmasını bozacağını" söylersiniz. Ürün İş Listesi, yine de dinamik olmalı, teknoloji, sistem, gereksinimler ve müşteri hakkında anlaşıldığı gibi her hikayenin sıralaması ve tahminleri değişiyor. Tipik olarak, Ürün İş Listesi'nden raporlanan şey, kullanıcı hikayelerinin sayısı ve toplam hikaye puanlarının sayısıdır. Bunların öncelikler değiştikçe değişmesi, yeni gereksinimler eklenmiş, geçersiz gereksinimler kaldırılmış ve daha fazla bilgi öğrenilmiş olması gerekir.


2
"Hikaye için yeni puanlar" bölümü hariç tüm bunlara katılıyorum. Hikayenin kapsamı değişmedikçe, hikayeye atanan orijinal noktalar değişmemelidir. Gördüğüm kadarıyla, o kısmı olmadan, yazdıklarınız tam olarak C seçeneğidir.
Eric King

@EricKing İlk paragrafta sunduğum seçenek, bir ya da iki hikaye için hikayenin çözülmesine neden olabilecek iş öncelikleri değişikliklerini hesaba katmanın yanı sıra Seçenek A'dır. Seçenek C'yi savunmuyorum çünkü bitmiş işlere dayanarak “tahmin etmemelisiniz”, ancak ekibinizin tahmin prosedürünü uygulayın.
Thomas Owens

1
Tahminim aslında eğitimli bir tahmin olduğu için "tahmin et" ve "tahmin et" değerlerinin yaklaşık olarak eşit olduğunu düşünüyorum. Yine de dediğim gibi, ilk paragrafınızdaki son bit dışındaki her şeye katılıyorum. Ve cevabın geri kalanının tümüne katılıyorum. Ancak A seçeneğinin özü, sadece hikaye üzerinde bazı çalışmalar yapıldığı için yapılmaması gerektiğini düşündüğüm hikaye noktalarını ayarlamaktır. Bunu kaldır ve C seçeneğiyle kaldın
Eric King

10

Bunun hakkında çok fazla düşünmek, olduğundan daha karmaşık görünmesini sağlıyor ... Aslında oldukça basit:

Seçenek c

Eksik hikayeler puan değiştirilmeden ürün birikimine geri döner. Bir sonraki sürat planını ve ne yapılabileceğini planlarken, tartışma işin çoğunun zaten yapıldığı gerçeğini içermelidir. Eğer takım onu ​​sprint içine sığdırabileceğine karar verirse, orjinal puanlarıyla birlikte girer. Aksi takdirde, birikimde kalır. Bitti. Puanlar, hikayenin tamamlandığı sprint'e verilir.

Yardımcı olursa, kullanıcı öyküsü başına ayrı bir "kalan işi" metrik olarak izleyebilirsiniz, böylece sprint sonunda öykü tamamlanmadıysa, kalan tahmini çalışma öyküye not edilebilir ve ne zaman hesaba katılabilir? sonraki bir sprint içine dahil edilmesini planlama. Fakat o zaman bile, orijinal hikayenin puan değerini değiştirmeyin.


3

Raporlama aracınız A seçeneğini doğru olarak kullanamıyorsa, ölçümlerinizi hiç kullanma umudunuz olmadığı sürece B seçeneğiyle giderim.

Bazı durumlarda, B seçeneğini VEYA kapatmak üzere olduğunuz eski görevin kapsamını daraltmak ve kalan kapsam için yalnızca yeni bir görev oluşturarak ne kadar kapalı anlamına gelmediğini çarpma. Bu, tarihi anlamsal olarak daha anlamlı kılar ve genellikle görevi daha da aşağıya indirmeyi düşünmeniz gereken yerleri belirtir. Bazen bu mümkün veya mantıklı değildir ve bu kadar büyük veya bu düzeyde bir sorunla karşılaşan bir göreviniz vardır.

düzenleme: Bu, (OP'nin varsaydığına inanıyorum) neredeyse tamamlanmış bir çalışmanın öncelik sırasına indirilmediğini ve önceki çabadan elde edilen kazanca ulaşılmasının listede çalışmaya devam etmesini sağlayacak kadar yüksek tuttuğunu varsaymaktadır. Bazı dükkanların bunu yapmadığını biliyorum, ancak çalıştığım çoğu yerde, bir şey dramatik bir şekilde değişmediyse, basit devam etmek için yeterince değerli olacak şekilde tamamlanmış bir artık işi bitirmeyi düşünün. Bağlamı değiştirmenin cezası genellikle sırayı değiştirmeye değmez.


B Seçeneği tehlikelidir, çünkü Bitti Tanımını bozma olasılığı yüksektir. “Ne diyorsun, hikayenin bir kısmı Done?
Robin Green,

Yapılan tanımı nasıl tanımladığınıza ve nasıl kapatılacağınıza bağlı olarak yapılan tanımlamayı değiştirebilir. Eğer bir tasarımda, göstereceğiniz kısmın, bağlanması için gerçek dünyaya sahip olmadığı yeterince erken bir yaştaysanız, kanıtlanamayan işten çıkmak ile sadece kanıtlanmış işten çıkmak arasında bir fark bulmuyorum bir atma testi koşum tarafından özellikle tehlikeli bir fark. Canlı bir ürün için piyasaya sürülecekse veya dağıtılmaya başlıyorsanız, bu farklı olacaktır.
Bill

3

Taşınmakta olduğumuz Kullanıcı Hikayesinin kısmen tamamlandığı göz önüne alındığında, bir sonraki Sprint Planlama oturumunda doğru bir şekilde nasıl tahmin ediyoruz?

A'dan C'ye kadar olan seçeneklerin iyi olduğunu sanmıyorum, çünkü bir takımın hızıyla ilgili en önemli şey (bence) ne olması gerektiği, ortalama hızdır ve verilen herhangi bir süratin hızının yükselip yükselmediğidir.

Bir kullanıcı hikayesi tanımlandığında, kabul kriterleri olmalıdır. Kabul kriterlerinde şey ise değil yapılır, daha sonra ekip sadece noktalarının herhangi kazanmıyor. Hikaye bittiğinde (PO tarafından kodlanmış, test edilmiş ve kabul edilmişse), ekip tüm puanları alır.

Bu, ekip belirli bir süratin süratinden ziyade ortalama süratine odaklandığı zaman işe yarar.

Kitabındaki M. Cohn gibi ben de ya hep ya hiç senaryosunu tercih etme eğilimindeyim. Ne de olsa, 8 puanlık bir hikayenin 5 puanını tamamlayıp tamamlamadığınızı tahmin etmeye çalışmak, ya da sadece 6 ya da 7 sadece başka bir tahmin oyunudur. tahmini yol. Sadece en basit yöntemle ve gerçekten tamamlandıktan sonra tüm puanları elde ederken gitmek muhtemelen daha iyidir.

M. Cohn'u kitabından alıntı yapmak¹ (vurgum):

Genel olarak sayma hızına karşı ya hep ya hiç ya da hiç durma tutumundan yanayım: bir hikaye yapılırsa (ürün sahibi tarafından kodlanmış, test edilmiş ve kabul edilmişse), ekip tüm puanları kazanırsa, ancak hikaye hakkında bir şey yoksa Yapılmadı, hiçbir şey kazanmıyorlar. Bir yinelemenin sonunda, değerlendirmenin en kolay yolu budur: Her şey yapılırsa, tüm puanları alırlar; eğer bir şey eksikse, puan alamazlar. Takımın bir sonraki yinelemede hikayenin geri kalan kısmını üstlenmesi olasılığı varsa, bu iyi sonuç verir. İlk yinelemedeki hızları beklenenden biraz daha düşük, çünkü bir hikayeyi kısmen tamamlama konusunda kredisi yoktu. Bununla birlikte, ikinci yinelemede, hızları beklenenden daha yüksek olacaktır, çünkü yinelemenin başlamasından önce bir takım çalışmalar tamamlanmış olsa da, tüm puanları alacaktır.Bu, herkesin çoğunlukla takımın zaman içindeki ortalama hızına ilgi duyduğumuzu hatırladığı sürece işe yarar, belirli bir yinelemede hızın yükselip alçalmadığına değil.

İle Çevik Tahmin ve Planlama , Kısmen Tamamlanmış Hikayeleri Yeniden Tahmin Etmek, s.66

Ekibim daha önce bazı itirazlara rağmen kısmi puanlar vermeyi denemişti ve hiç işe yaramadığını düşünüyorum. (Artık yapmıyoruz ... devam et) Bu özellikle, öykülerin bir takım olarak tahmin edilmesi gerektiği için geçerlidir , ancak bunun üzerinde sadece bir kişi çalışıyorsa, takımın çalışması daha zor olacaktır . Bir bireyin gerçekte ne kadarını tamamladığını bilmek Çevik, bir sprintin ne kadar "güzel" göründüğünden ziyade bir takımın ortalama hızıyla daha fazla ilgileniyor.

Söyleniyor, yazar yok ekibi bir sonraki yineleme kalan çalışmayı çözecek gibiyse kısmi noktaları atama kabul edilebilir söz. Bu durumda, ekip kalan işi tahmin eder ve ne büyüklükte olursa olsun hissedecekleri boyutta yeni kullanıcı hikayelerine böler. Yazarın belirttiği gibi²:

Birleşik tahminlerin orijinal tahminde eşit olması gerekmeyecek…

² Aynen, s.66

Takım için en iyi öneri, bu tür bir sorunu önlemek için hikayeleri yeterince küçük bir boyuta bölmektir.

Ancak, tamamlanmamış öyküler için puan tahsis etmenin en iyi iki çözümü, tamamlanmamış öykülere sahip olmamak ve kısmi kredinin bir sorun olmadığı kadar küçük öyküler kullanmaktır.

İt Aynen, s.67

Bu yardımcı olur umarım.


2

Buna kesin bir cevap görünmediğine şaşırdım. "Seçenek D, kukla" korosu bekliyordum!

Açıkça net bir şeyleri eksik gibi görünmediğimize göre, bunun, her takımın nasıl çalışmak istediklerini ve onlar için en önemli olan ölçütleri temel alarak kendileri için alması gereken kararlardan biri olduğunu düşündük.

Seçenek B’yi dışlayan, testlerimizin, destek belgelerinin ve sürüm notlarımızın temelini oluşturduğundan, uygulamış olduğumuz kullanıcı hikayelerinin doğru kayıtlarının tutulması gerektiğine karar verdik.

Daha sonra sprint planlamasını doğru bir şekilde yapabilmenin zorunlu olduğunu düşündük - bu seçenek C'yi dışlıyor.

Bu nedenle, A seçeneğinin bizim için uygun olduğu sonucuna vardık. Bir sprint içinde kısmen tamamladığımız hikayelerin hikaye puanlarını, sonraki sprintlerde onlar için uygun şekilde planlayabilmemiz için yeniden tahmin edeceğiz. Zamanla ürün birikimi, uygulamış olduğumuz hikaye puanlarının miktarını biraz rapor altında tutacaktır, ancak bu, diğer seçeneklerden herhangi birinden daha az problem teşkil edecektir ve muhtemelen kayıt tutma ve raporlama yöntemlerimizi değiştirerek çözülebilir.


1

Sprint yinelemesinde harcanan amaçlar için harcanan zamanı izleriz, (bir kullanıcı hikayesiyle ilgili görevlere yakılmış saatler) ve PO'nun hedefi bir sonraki sprint boyunca devam etmek istiyorsa, sivri kullanıcı hikayesini birlikte hareket ettiririz. aynı noktaları.

PO'nun hedefi yerine başka bir şey yerleştirmekse, bitmemiş hikayeyi biriktirip, istediklerini yaparız. Asıl puan tahmininden çıkmak benim tavsiyemdir, çünkü çiğneyebildiğinizden daha fazla ısırma alışkanlığınız varsa, her bir sprint, bir sprint içinde tamamen bitmemiş ve temiz olmayan bir hikayede "tamamlıyor" olacaktınız. test edilmiş ürünler

Eğer sprintte bir şey bırakmak isteseydiniz, işaret ettiniz ya da gemi açmak zorundaysanız, orijinal hikayenin içinde bir noktaya değineceğinizi, tamamladığınız noktaya ulaştığınızı ve daha küçük bir parça yapacağınızı düşünürdüm. yinelemeniz için. Ardından kalan kısım tekrar işaretlenip listeye alınabilir. Bu, yeniden tahmin etmek için bir fırsat olacaktır, çünkü hikayenizi dilimlere ayırmak için ekibinizle aynı fikirdeydiniz.


0

Sorulması gereken ilk soru, Bir Öykü Noktası ne anlama geliyor? Bir hikaye noktasını "Ne kadar iş mühendisliği yapıldı" olarak tanımlarsanız, o zaman herhangi bir cevap verilecektir. Ancak bir hikaye noktasını "İşletmeye ne kadar değer iletilir" olarak tanımlarsanız, bir hikaye% 100 tamamlanana, kabul edilip% ​​100 teslim edilinceye kadar kredi kullanmamak önemlidir. Neyin tamamlandığına dayalı bir sprint sonrası hikaye noktalarını değiştirmek sadece asıl sorunu gizleyecektir: a) hikaye hakkında net bir anlayış yoktu, b) hikaye çok kaba tanımlandı, c) ölçülebilir kabul kriterleri bulunmadığında, d (hikayeyi tamamlamak için gereken görev ve bağımlılıkları yeterince derinlemesine anlayamamak, e) hikayeyi test etme çabasını vurgulamak, f) çok fazla hikaye puanı çekmek ya da g) ... nedeninizi buraya eklemek ...

Çevikliğin amacı, öngörülebilirken esnek olmaktır. Tutarlı olmanın en iyi yolu, bence orijinal hikaye tahminlerini değiştirmeden neyin yanlış gittiğini bulmak.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.