Jesteśmy małym zespołem 4 deweloperów raczej zielonym w Scrumie. Pochodzący z całego kraju często robimy sobie dziwne dni wolne lub całe tygodnie wolnego, aby wrócić do domu. Dlatego pojemność naszego zespołu zmienia się drastycznie z jednej iteracji na drugą z powodu rocznych urlopów, co prowadzi do bardzo różnych prędkości z jednej iteracji do drugiej. Jak uwzględnić pojemność zespołu podczas szacowania prędkości na spotkaniu planowania? Dane historyczne będą odzwierciedlać bardzo różne zdolności i nie możemy czekać jednego roku, aby uzyskać średnią dla naszej oszacowanej prędkości.
źródło
Prędkość może się różnić, nawet jeśli pojemność pozostanie taka sama.
Więc po prostu zaufaj swojej prędkości, że sama zajmie się różną wydajnością, tj. Zakładając, że jesteś w 3. sprincie, weź średnio z dwóch ostatnich ukończonych sprintów, aby przejść do następnego sprintu. nie martw się o wariancję pojemności.
źródło
Prędkość jest wskazówką, a nie miarą. Po prostu weź średnią wszystkich twoich sprintów (uwzględniając odchylenie standardowe) i średnią swoich najgorszych trzech, średnią twoich najlepszych trzech i powiedz: „Zdecydowanie to zrobimy, możemy to zrobić, nie dostaniemy te zrobione ”. Rysując trzy linie przez (w pełni oszacowane) zaległości przy użyciu tych trzech prędkości i surowego terminu (udawaj, że to 12 sprintów i 12x najgorsza prędkość to 75, 12x Twoja najlepsza to 120 i 12x Twoja średnia to 90. W zaległości wynoszącej 100 punktów , nawet w najgorszym przypadku możesz zrobić trzy czwarte, najlepiej zrobić wszystko i średnio dostarczyć większość.
Dzięki tym danym, Twój PO może podejmować wszystkie decyzje, których potrzebuje MUSI, chcielibyśmy mieć to, czego nie miałby pominąć.
Ostatecznie, rzeczy się zmieniają, pojawiają się wymagania i, cóż, rzeczy znów się zmienią. Nie rzucaj kotletów w matematykę, aby uzyskać konkretną liczbę, dokładne zakresy są wystarczające do tego rodzaju rzeczy. Oprzyj się na problemach z oprogramowaniem, a nie na zaległościach.
źródło