Ja się dziwię czemu u wszystkich są jakieś patoscrumy gdzie niespalony task to problem albo że tester nie ma co robić na początku xD u mnie scrum wygląda tak:
-główny cel planowania sprintów to po prostu wiedzieć ile można dowieźć przez sprint. Można dowieźć =/= na pewno dowieziemy, czasem czegoś nie zrobimy i się nic nie stanie, czasem coś dobierzemy, ogólnie wyciągamy średnią SP za poprzednie sprinty by się orientacyjnie planować.
-osobne taski deweloperskie i testerskie oraz osobne ich szacowanie. Zazwyczaj testy są sprint później by robić development bez spiny. Jakby testy się nagromadziły i by miały być dwa sprinty później (co wiem dzięki wycenom), to rezygnujemy z ficzerów na siłę i robimy jakieś refaktory, podbijamy biblioteki, itp. (co też wyceniamy by wiedzieć ile SP można na spłacanie długu wykorzystać)
-nie dowiozłeś taska na koniec sprintu? Nie ma sprawy, przeszacuj go sobie np. z 5SP na 2SP, wtedy wiemy że teraz spaliliśmy 3SP, a do kolejnego sprintu dorzucimy nieco mniej by było miejsce na dokończenie tych 2SP
-szacowanie relatywne, mamy jakieś taski wzorcowe na 1, 3, 5SP i staramy się nowe do nich porównać. Jak coś jest większe niż 5SP to staramy się podzielić.
-1SP na testy =/= 1SP na dewelopment =/= 1 manday. Po prostu to wychodzi w praniu i trzeba paru sprintów by wiedzieć ile się spala. U nas to wyszło jakoś 5SP na sprint na osobę na development, 4SP na osobę w testach, na tej podstawie się planujemy, ew. proporcjonalnie ucinamy jak są urlopy.
Ogólnie staramy się podchodzić profesjonalnie do pracy, czyli z jednej strony spokojna, jakościowo dobra, ale bez opierniczania się praca, z drugiej brak nacisków z góry bo i tak zrobimy podobnie SP jak zazwyczaj (jak ma wejść na już coś nowego pilnego, no to trzeba coś wywalić ze sprintu) i szacunki co kiedy zrobimy są w miarę jasne i przewidywalne, więc PM wie co i kiedy dowieziemy, wszyscy zadowoleni. Scrum to takie narzędzie które jednocześnie ma nie przeszkadzać i nie stwarzać presji, ale jednocześnie dawać jakieś estymaty i myślę że udaje nam się to robić. Z tym że trzeba wzajemnego zaufania i/lub np. niedopuszczania PM do szacowania. Ten obecny scrum to najlepsza metodologia w jakiej pracowałem, chociaż konkurencji za dużej nie było, wcześniej to był januszsoft gdzie prezes z zespołem planował taski co do kwadransa, oraz ziomek co postanowił być software housem i dał mi wszystkie taski z jednego projektu i bym sobie robił po kolei (niby fajnie, ale totalnie nie byłem w stanie określić czy coś mi zajmie jeden czy pięć dni).