Bywa ona przez wiele zależności nieprecyzyjna, a przez to zwodnicza.
Istotą szacowania jest jego niedokładność. Ważne, żeby wszyscy zainteresowani wiedzieli, że dane są wyssane z palca.
Podczas ostatnich dni dowiezienia wartości robi się zazwyczaj trytytkowanie, gdzie okłamujemy sami siebie, ze poprawi się później.
To dopychanie kolanem, kombinowanie jak przepchnąć dalej, czyli kopanie samego siebie w gluteus maximus - nie rozumiem. Alternatywnie, ktoś was skrzyczy (i to delikatnie, bo jak przesadzi to się przeniesiecie do konkurencji).
Oraz rzecz najważniejsza - dostarczenie dobrej wartości biznesowej jest lepsze niż dowiezienie ledwo działającej usługi o niskiej jakości technicznej.
Z punktu widzenia biznesu albo działa, albo nie działa. Dlatego trzeba pilnować swojego DoD.
Jak wy dealujecie z estymacja? Bo jedyne co to mając dobre DoD trzeba czasowo rozciągnąć dość mocno taska, przez co biznes zawsze jest smutniejszy, obarczając was winą..
Zależy od projektu. Na początek prosty przypadek - klient zewnętrzny, kontrakt podpisany, data oddania ustalona, kasa też. To po co tu cokolwiek estymować? Szkoda czasu na takie bzdury. Ktoś stwierdził, że bańka starczy na ten projekt i jedziemy.
Projekt "zwinny", nie ma sensu szacować całości, bo się jeszcze 500 razy zmieni zanim będzie koniec. Można jedynie szacować bieżącą pracę (kilka tygodni do przodu). Sens tego jest taki, że widać na ile zespół ogarnia projekt. Im trafniejsze szacunki, tym lepiej podzielone zadania, sensowniej opisane wymagania. Te 20% błędu będzie nawet w idealnym układzie, bo albo ktoś się szybciej upora z zadaniem, albo przeziębi i weźmie 3 dni wolnego. Co ważne - nie warto poświęcać dużo czasu na szacowanie. Błąd i tak będzie duży, więc jakieś zadania rozpoznawcze tak, ale takie nakierowane na rozpoznanie bojem problemu a nie określenie czy coś powinno zająć dzień, czy 2 tygodnie. W skrócie, tak jak poprzednio - nie ma sensu szacować. Te dane są zbyt niedokładne.
Jak biznes chce sobie wyciągać wnioski, to patrzy na dane historyczne (dane, a nie wróżby), ile zadań zostało zrobione w czasie X, liczy prędkość, przykłada do tego co zostało w backlogu do zrobienia i ma wszystko czego potrzeba.