Scrum fazla tahmin ve yeniden planlama

İlk Sprint'imizin ortasındayız ve üzerimizde şafak vakti var: Fazla tahmin ediyoruz!

Bu 2 haftalık tekrar için 114 ideal saat planlamıştık ve ilk haftanın sonunda tüm Sprint'i bitirdik. Şimdi ne yapacağız? "Kitap", bir sonraki yüksek öncelikli öğeleri biriktirme listesinden almamız gerektiğini ve alacağımızı söylüyor. Yine de, onları yakma tablosuna nasıl ekleriz? Bu hikayeleri, en başından beri oradaymış gibi açıklamak için yeniden yazıyor muyuz? Ya da sadece onların üzerinde çalışmaya başladığımız gün tahminlerini y eksenine ekliyoruz (90o açı atlaması gösteriyor)?

Herhangi bir geri bildirim açığız!

Burndown şemasına sahip olmanın amaçlarından biri, zaman içinde ve şeffaf bir şekilde değerin nasıl sunulduğunu göstermektir.

Yeni kullanıcıların öyküleri başlangıçta sprintte değildi, bu yüzden olduklarını iddia etmek biraz zor görünüyor. Bunları şu anda burdown grafiğine ekleyerek, mevcut tahmin seviyesinin hala ilk evrim safhalarında olduğunu doğru bir şekilde göstereceksiniz.

Bu, hem sizin hem de ürün sahibiniz için iyidir. Bu proje yönetimi sistemini kullanmanın nasıl daha iyi tahminci olabileceğinizi gösterecek ve gösterecektir.

Başından beri aşırı, sonra da tahmin altında, sonra da biraz daha az ama çok az tahmin ettiğinizi görebileceksiniz ... ve sonunda ilerledikçe tahminlerdeki gelişmeleri göreceksiniz.

Kullanıcı hikayelerini tahmin etmenin bir sprint'in en zor kısımlarından biri olduğunu düşünüyorum ve sadece ekibiniz birlikte gelişmeyi öğrendikten sonra süreçte daha verimli hale gelecekler. Bunu, kullanım planı gibi kullandığınız araçlarla göstermeniz iyi olur.

Sprint'i iptal ederseniz ve mevcut süratinizi dikkate alarak bir sonraki sprint'i planladığınızda zarar vermez .

Resmi Scrum Rehberinden :

Sprint'ler, Sprint süresi kutusu bitmeden iptal edilebilir. Sadece Ürün Sahibi Sprint'i iptal etme yetkisine sahiptir, ancak paydaşlar, Takım veya ScrumMaster'ın etkisi altında bunu yapabilir.

Sprint planlama, ürün sahibi, scrum master ve ekibi ile bir tartışma içinde yapılması gerektiğinden, bir sonraki kullanıcı hikayelerini seçmek tersine verimli olacaktır.

Biraz önceden olmanız durumunda, bir sonraki en yüksek öncelikli hikayeyi seçmiş olabilirsiniz, ancak burada durumunuz çok farklı.

Bir yazma grafiği ekleyebilirsiniz . Belirsizlik olmadan, ne zaman ve ne kadar yeni iş eklediğinizi gösterirler:

Bu grafik, ekibin yineleme 5'e 20 iş puanı daha eklediğini göstermektedir. Bu resim yinelemeleri gösterir, ancak günlerle de çalışır.

Bunu görselleştirmek için bir dizi farklı teknik vardır.

Bunlardan biri, yeni öykülerin eklendiği gün y eksenine (yatay eksen) bir ofset getirmektir, gerçek burndown grafiği daha sonra orijinal "0" seviyesinin altına iner.

Bir diğeri, en başından beri oradaymış gibi davranmaktır (CGI tabanlı burndown grafiklerini kullanmanız çok daha kolaydır).

Ve kendinize ait olabilirsiniz.

En önemli şey, bu durumda ne yapmak istediğiniz konusunda anlaşmaya varmak için bunu ekip, scrum ustası ve ürün sahibi arasında tartışmaktır. Scrum'da temel kurallardan başka bir şey yapmanın kesinlikle sabit bir yolu yoktur. Scrum, zaman içinde ortamınızın ihtiyaçlarına en uygun şekilde gelişmek içindir.

OP'nin problemini üç ayrı soruya bölmek istiyorum :

1. Sprint'e devam edilsin mi, iptal edilsin mi?
2. Sprint devam ederse kalan hafta ne yapmalı?
3. Bir sonraki sürat nasıl planlanır?

Diğer sorularda bahsedilen burndown ve burn-up çizelgeleri, kullanışlı olsa da, OP'nin "şimdi ne yapıyoruz?"

Devam et veya iptal et : Pierre ile birlikteyim, bu sprint'i iptal edip hemen bir sonrakini planlamaya başlamak uygun. Başka takımların ve sprint'lerin senkronize edilmesi gerekiyorsa sprint iptali bir seçenek değildir (Scrum gurusların çoğu senkronize edilmelerini tavsiye eder).

Sprint devam ederse: Devam eden çalışmayı sınırlayın . Bir kerede yalnızca bir hikaye üzerinde çalışın, bir haftadan az bir süreye sahip olduğunuz bitirmeye odaklanın. Sprint sonunda kısmen bitmiş durumda hiçbir hikaye olmadığından emin olun.

Bir sonrakini planlama : buradaki seçenekler göreceli boyut tahminini denemek veya hikaye noktası-kişi-gün denkliğini ve odak faktörünü, Henrik Kniberg'in "Trençlerden Scrum ve XP" kitabında açıklanan bir yaklaşım olarak kullanmaktır. Zaten farklı bir başlıkta tartıştık .

Yarı sürede tamamlanması tahminlerin çok büyük bir varyasyonudur. Bana göre, bu, ekibinizin gerçekte yaptıklarının, kullanıcıların Sprint'in başında beklediklerinden sapma riski olduğunu gösterir. Buna ek olarak, bir Sprint'in şimdi PO'dan yeni geri bildirim alma zamanı geldiğinde yeterli işlevsellik sağlaması bekleniyor.

Dolayısıyla, PB'nin üst kısmındaki şeyleri kapma ve devam etme riski, PB'nin üstündeki öğelerin güncel olmaması (hem içerik hem de öncelik açısından) ve Ekibinizin son Sprint'te yanlış bir şey aldığıdır. ve PO'dan geri bildirim almadan sadece bu hatalar üzerine inşa edeceksiniz.

En makul hareket yolunun Sprint'i aramak, her zamanki Sprint gözden geçirme, toplantı ve geriye dönük planlama planınızı tutmak ve bir sonraki Sprint'te başlamak olduğunu söyleyebilirim.

Burndown şeması konularına gelince, orijinal soru bunun ne için olduğunu kaçırıyor gibi görünüyor. Gerçekten sadece Sprint sırasındaki ilerlemeyle ilgili bir sorun olup olmadığını belirlemek için bir araçtır. Tarif edilenlerle birlikte, bu durumda Sprint'in 2 veya 3. gününde, Takımın Sprint görevlerinin zamanlamasından çok daha önce olduğunu göstereceği zaman bu durumda burndown şeması devreye girmiş olmalıydı. Ardından, "Neden?" Sorusunu sorarsınız ve tahminlerinizin çok yakında mı yoksa programcıların görevleri yanlış mı yorumladığını veya bir şekilde raylardan bir şey çıkıp çıkmadığını belirleyin.

Ancak, burdown grafiğini görmezden geldiğinizde ve garip bir şey yokmuş gibi gezindiğinizde, "kitap" size söylediği için ürettiğiniz anlamsız bir şeymiş gibi davranıyorsunuz. Kanımca, PB'nin üst kısmından biraz daha fazla şey çekmeye ve ikinci hafta devam etmeye karar vermeniz gerekiyorsa, ikinci hafta için yeni bir burndown başlatın (ve sonra bunu yaptığınız gibi görmezden gelebilirsiniz) ilk hafta).

Ne yapacağım konusunda ürün sahibine danışır ve işin getirildiği tarihte mevcut sprint'e eklerdim. Bir yakma tablosundaki ek çalışmaları izleyebilirim. Biraz lunapark treni gibi görünen yanık tablosuyla ilgili bir sorunum yok. Scrum üyeleri görevlerde kalan süreyi tahmin ettikleri için bu zaten olur.