Wpis z mikrobloga

@rrobot: po prostu moim zdaniem wypadałoby albo wyceniać nie 2 tygodnie tylko więcej (np miesiąc) albo faktycznie nie traktować niedowiezionego sprintu jako porażki tylko "no cóż, bywa". Jak masz 2 tygodnie i np 3 programistów w zespole to margines czasowy jest na tyle mały że wystarczy że na chwilę #!$%@? się środowisko albo wpadnie jakiś priorytetowy błąd i już nie zrobisz wszystkiego co zaplanowałeś xD a jak wyestymujesz z górką to
@lucidwires:
Nie rozumiem dlaczego na koniec sprintu nie można spytać co się stało, że nie wyszło?

Jeżeli to jest coś, na co zespół miał jakiś wpływ, to powinien umieć samodzielnie zdiagnozować problem (albo dążyć do wykształcenia takiego mechanizmu) i do niego jakoś podejść. Może wymagania nie były jasne? Może nowa technologia i nie zarezerwowano ekstra czasu na eksperymentowanie? Może scope creep? Może zespół zależał od innego i źle sobie zaplanował pracę
@lucidwires: @rrobot: przede wszystkim trzeba zrozumieć ze w scurmie nie estymujesz czasu ile zajmie dane zadanie, a złożoność zadania. Wtedy mając takie wyceny po jakimś czasie widać ile dany zespół jest w stanie zrobić punktów w czasie sprintu. Wtedy wiadomo ile mniej więcej trzeba wziac na sprint zeby zdążyc ze wszystkim. I jezeli zazwyczaj robicie 30, a nagle zespol zrobil 15 to tak, trzeba sie wspolnie zastanowic dlaczego. Czy wyceny