Odpowiedź na pytanie z tytułu jest dość krótka: użyj metody “Bucket system” 😎 W tym poście dowiesz się jak użyć tego sposobu i co on może Ci dać.
Na początku należy przygotować przestrzeń. Najlepiej spore biurko lub stolik oraz karty ze story pointami (jak w scrum pokerze). Karty należy ułożyć w kolejności od najmniejszej do największej. Możesz też, zamiast kart, przygotować to np. na tablicy, rysują odpowiednią tabelę z „przegródkami” na kolejne liczby 0, 0.5, 1, 2, 3, 5… . To właśnie te numery będą tworzyły „wiaderka” (od ang. bucket) – rozmiary Twoich hsitoryjek.
Następnie:
- Każdą historyjkę opisz na oddzielnej kartce.
- Wylosuj dowolną historyjkę i umieść ją na “8”. Przed umieszczeniem, przeczytają ją wszystkim uczestnikom.
- Taka historyjka będzie referencyjna – wszystkie kolejne będą się do niej odnosiły (większe/mniejsze/takie same?)
- Wylosuj kolejną historyjkę – przeczytaj ją zespołowi i poproś o umieszczenie na skali, w odniesieniu do tej referencyjnej.
- Zrób tak samo z trzecią historyjką.
- Rozdaj historyjki każdemu członkowi zespołu – dla każdego inne.
- Poproś każdego o ich przeczytanie i umieszczenie w odpowiednich “bucketach”, czyli przypisanie do wartości Story Points. Każdy robi to osobno, bez rozmów z innymi.
- Poproś zespół o przegląd swoich estymat – gdy ktoś się nie zgadza z szacunkiem innego członka zespołu, może temat podnieść i wówczas następuje wspólna dyskusja, aż do uzyskania konsensusu.
- Idźcie na piwo/kawę, bo zrobiliście dobrą robotę 😀
Kilka uwag:
- Powyższa forma może sprawdzić się od ręki, ale być może widzisz w niej luki albo przestrzeń do eksperymentów – śmiało! Daj znać jak Ci poszło :)
- Można próbować robić to samo z wykorzystaniem narzędzi online, gdy pracujesz z zespołem rozproszonym, ale jest to dużo wolniejsze (np. wykorzystując białe tablice online albo Google Spreadsheet).
- Niektórym nie podoba się to, że brakuje szerokich i głębokich dyskusji co do tego jak będzie realizowana historyjka, bo z reguły na „Refinemencie” rozmawiają o sposobach implementacji danej historyjki, pułapkach itd. Warto jednak pamiętać, że ten sposób tego nie zabrania – do bardziej szczegółowych dyskusji służy m.in. moment przeglądu tego co ułożyliście. Jednocześnie trzeba pamiętać, że to są szacunki, a nie deklaracje (np. w czasie wyrażone) i celem tego ćwiczenia jest szybka oszacowanie rozmiaru, a nie dogłębne zrozumienie jak napisać kod.
- Tak szybka praca zwiększa nieco ryzyko niewyłapania jakiegoś większego problemu. Coś za coś ;-)
- W związku z powyższym można też użyć tego pomocniczo – najpierw zrobić jedną dużą sesję i oszacować np. 50 historyjek, a potem na kolejnych sesjach doskonalenia backlogu dopieszczać je (razem z estymatami), mając już jako taki ogląd na większą część.
- Ciekawą rzeczą w tej metodzie jest to, że uczy trochę zaufania i innego punktu widzenia na to jak inni członkowie zespołu szacują.
- Jeśli jesteś Product Ownerem, to możesz użyć tej techniki do estymowania wartości biznesowej razem ze swoimi interesariuszami – szczególnie polecam, gdy trzeba pogodzić wiele różnych potrzeb.
- Największa magia zaczyna się dziać, gdy już wszystkie historyjki rozłożone są na stole – dyskusje potrafią być bardzo burzliwe 🔥
Do ilustracji tego posta użyto zdjęcia z Rawpixel.