Kto pyta nie błądzi – czyli jak i dlaczego zadawać pytania zespołowi. [Z cyklu wycena skrojona na miarę]

Na przeprowadzenie refinementu składa się nie tylko dobre opisanie czy omówienie zadania, ale też sprawne moderowanie spotkania. Po właściwym wprowadzeniu przychodzi czas na dyskusję pomiędzy uczestnikami, czego wynikiem jest wycena w story pointach. Aby spotkanie było owocne, nie powinieneś bać się zadawania pytań.

Pytania pomocnicze są jednym ze sposobów polepszenia jakości estymacji. Aby je zadawać, nie trzeba być programistą. Wiedza techniczna jest jak najbardziej przydatna, ale nie zawsze obowiązkowa – nie musisz przecież  zespołu zastąpić, czy sugerować rozwiązania. Głównym celem Twoich pytań jest aktywizacja grupy oraz trzymanie dyskusji w ryzach. Musisz jednak pamiętać, że pytania powinny być otwarte, trafiać w kontekst i mieć charakter pogłębiający.

Z mojego doświadczenia wynika, że zwykle na etapie omawiania zadania zespół  potrzebuje zachęty do wyciągnięcia kart i najczęściej prowadzi zażartą dyskusję techniczną zamiast głosować.

Na tym etapie najlepiej kontrolnie zapytać o gotowość do wyceny.  Standardowe pytanie „Czy możemy wyceniać?” warto zastąpić innym, np. :

• Jakich informacji brakuje wam, aby zagłosować?
• Czy omawiany obszar będzie częścią realizacji tego zadania?
• Czy to zadanie potrzebuje koncepcji technicznej?

Skutecznym rozwiązaniem może okazać się  określenie ram czasowych przewidzianych na omówienie pojedynczego zadania. Już na początku spotkania należy poinformować,  że celem jest wycena przykładowo sześciu zadań w godzinę. W przypadku wydłużającego się czasu, który zespół poświęca na omówienie strony technicznej zadania,  timebox może znacząco ułatwić moderowanie spotkania. Niestety nigdy nie masz pewności, czy przez wprowadzenie takiego ograniczenia nie utracisz ważnej dla projektu informacji.

Dużo trudniejszą, choć niestety nierzadką sytuacją jest całkowity brak aktywności zespołu, który po zapoznaniu się z zadaniem nie przygotowuje kart i nie zadaje pytań.  Wtedy to ty powinieneś rozpocząć dyskusję stawiając między innymi poniższe pytania:

• Jak dobrze znacie ten obszar aplikacji?
• Kto ostatnio realizował podobne zadanie i mógłby przybliżyć innym problem?
• Jak rozumiecie problem biznesowy, który opisałem?
• Jaki diagram ułatwiłby wam wycenę?
• Czy to zadanie jest większe/mniejsze od poprzedniego?
• Którą część zadania chcecie, abym dokładniej opisał/rozrysował ?

Kiedy zespół zagłosuje i część osób zabierze głos, możesz posłużyć się kilkoma pytaniami pogłębiającymi:

• Twoja wycena jest o X punktów większa od większości. Jakie dodatkowe ryzyko widzisz?
• Dałeś X. Czy to oznacza, że bylibyśmy/ nie bylibyśmy w stanie zrealizować zadania w jednym sprincie?
• Jaka część Twojej wyceny to programowanie, a jaka to testy?
• Ile z tego chciałbyś przeznaczyć na refaktoryzację?
• Poprzednie zadanie wyceniliśmy na X. Czy to zadanie jest większe/mniejsze od poprzedniego?
• Twoja wycena to X. Jak widzisz zbudowanie tego rozwiązania?

Różnice w wycenach wynikają nie tylko z różnej znajomości danego obszaru aplikacji, czy doświadczenia w programowaniu. Istotna jest także odmienna dla każdej specjalności perspektywa (programista, tester, architekt) i posiadanie wizji, jak daną rzecz można zbudować. Wymiana spostrzeżeń pomiędzy osobami które dokonały skrajnych wycen,  może pomóc pozostałym głosującym w ocenie danego zadania i usprawnić kluczową dla wyceny wymianę informacji.

Nie musisz  bać się zadawania pytań – ostatecznie Twoja rola w omawianiu zadań nie kończy się tylko na ich przygotowaniu i przedstawieniu. Aktywna interakcja z zespołem z pewnością znacząco poprawi jakość wycen, a niejednokrotnie pomoże Ci też poprowadzić ku rozwiązaniu najtrudniejszą dyskusję. Poza tym –  zawsze łatwiej pytać, niż odpowiadać