[Wurmloch]

W jaki sposób w waszych teamach/firmach jest przeprowadzany refinement? Szukamy u nas sposobu na poprawę całego procesu, który wygląda w naszym przypadku tak, że mamy po dwa-trzy godzinne spotkania na sprint (2 tygodniowy). Omawiamy na nich backlogi, które przychodzą od biznesu z ogólnym opisem a my (team programistów oraz project manager) na tej podstawie piszemy kryteria akceptacji i wyceniamy effort. Jednak przez to, że na refinementach dla większości z nas jest to pierwsza styczność z danym backlogiem to kryteria akceptacji bywają niekompletne a effort nietrafny. Dodatkowo nasz PM uważa, że refinement jest u nas zbyt mało efektywny (nie zgadzam się z tym bo jak pisałem wcześniej zazwyczaj nic nie wiemy o omawianym zadaniu). Jeśli coś opisałem niekompletnie/nietrafnie to sorry ale jestem średni w tych tematach a mamy przedstawić swoje propozycje zmian ( ͡° ͜ʖ ͡°) #programowanie #programista15k #scrum

[Campell]

@Wurmloch: oj znam podobny schemat aż za dobrze, u mnie też często w trakcie sprintu okazuje się, że albo opis taska jest niewystarczający albo brakuje do niego jakiś innych danych i się to badziewie rozrasta. Najlepiej chyba by było abyście robili, krótki refinment (1h) z PM-em co ma trafić na następny sprint a potem druga godzinna już bardziej techniczna gdzie zapisujecie estymaty. Nie wiem tylko na ile to realne, u mnie

[laki1]

kryteria akceptacji bywają niekompletne a effort nietrafny.

@Wurmloch: Jak podczas refinementu nie ma osoby która tworzy backlog to tak się będzie zdarzać

[Cookiee]

@Wurmloch: u nas tworzeniem historyjek zajmuje się Analityk korzystając czasem z pomocy Team Leadera. Na Refinemencie omawiamy już historyjki z gotowymi acceptance criteria, zespół deweloperski jedynie zadaje pytania, które ewentualnie trafiają do biznesu. Jeśli odpowiedź na te pytania może wpłynąć na estymację, to dana historyjka zostaje ponownie omówiona na kolejnym refinement. Zazwyczaj jesteśmy w stanie od razu wyestymować historyjki, w sprincie mamy zazwyczaj dwa takie spotkania po godzinę każde

[wpiot]

@Wurmloch: mamy 2 refinementy w tygodniu, każdy po 1,5h. Pierwszy bardziej ogólny, drugi bardziej techniczny gdzie schodzimy bliżej rozwiązania. Trochę dziwne, ale domena trudna i sporo utrzymania.
W innych firmach spotkania miałem krótsze, ale mieliśmy na spotkaniach szefa który trzymał te spotkania w ryzach, do tego znał biznes i dodatkowo dobrego analityka.

[Priya]

Omawiamy na nich backlogi, które przychodzą od biznesu z ogólnym opisem a my (team programistów oraz project manager) na tej podstawie piszemy kryteria akceptacji i wyceniamy effort.

@Wurmloch: Tutaj jest błąd. Taski nie powinny przychodzić z zewnątrz, tylko ogolne wymagania powinny być zebrane przez Produkt Ownera. PO powinien przeanalizować ich sens, logiczna spójność i zebrać jako spójną wizję rozwoju produktu. Powinien też przedstawić też acceptance criteria.

W scrumie nie ma roli

[Emkacf]

Nie mamy typowego refinementu, bardziej planning (ale ja bym powiedziała, że to takie wszystko w jednym). Raz na dwa tygodnie omawiamy stories na dany sprint, poprawiamy w razie potrzeby i estymujemy complexity na zasadzie story points w skali fibonacciego (na razie testowo, bo może od story points odejdziemy). Ostatnio uznaliśmy, że za dużo czasu nam na to schodzi (1-1.5h) i ustaliliśmy, że każdy z nas przejrzy backlog przed meetem, a przy dużych

[Benio_Czarodziej]

@wpiot czyli marnujecie a 3 godziny devow tygodniowo na ref? Umarłbym

[laki1]

@Benio_Czarodziej: 3 godziny na dwa tygodnie

[wpiot]

@Benio_Czarodziej: tak, a w rzeczywistości nawet więcej :)
Na szczęście rzuciłem papierami
@laki1: 3 godziny w każdym tygodniu

[laki1]

@wpiot: a ciul, myslalem ze to do opa bylo. Sorry w takim razie

[Strus]

Jednak przez to, że na refinementach dla większości z nas jest to pierwsza styczność z danym backlogiem to kryteria akceptacji bywają niekompletne a effort nietrafny. Dodatkowo nasz PM uważa, że refinement jest u nas zbyt mało efektywny (nie zgadzam się z tym bo jak pisałem wcześniej zazwyczaj nic nie wiemy o omawianym zadaniu)

@Wurmloch: Product Owner nie robi u was swojej roboty - albo go nie ma, i to #!$%@?, nie