W trakcie Sprintu zespół spotyka się w celu omówienia przyszłych zadań – Refinement. Jest to spotkanie, które musi się odbywać się cyklicznie, ale nie powinno zajmować więcej niż 10% czasu Zespołu Deweloperskiego. Jeżeli wymagany czas jest dłuższy jest to sygnał, że coś jest nie tak. 

User Story / Bug/ Task 

Najlepszą metodą do określania potrzeb użytkownika jest zastosowanie User Story, lecz również inne zadania powinny być stworzone poprawnie. Jest to podstawa dla PO do maksymalizacji efektów pracy Zespołu Deweloperskiego. Idealne zadanie powinno się charakteryzować zastosowaniem reguł INVEST 

Independent  

Każde zadanie powinno być niezależne od innych. W inne sytuacji estymacja i praca zawierają w sobie wiele niepewności, przez co zadanie może być trudne do zrealizowania. Kolejnym argumentem jest ich przemieszczanie – gdy zadanie jest zależne od wielu innych jest to utrudnione i może się okazać konieczna realizacja ASAP.  

Negotiable 

Podczas tworzenia oprogramowania relacje i wpływ innych czynników mogą być na tyle duże, że wcześniej zaplanowane i zaakceptowane zadanie może już być nieaktualne. Dlatego nie powinno się określać sposobu dojścia do rozwiązania, ale cel i kryteria oceny akceptacji. 

Valueable  

Wartość powinna być zawarta w każdym zadaniu. W sytuacji, gdy wydaje się że zadanie jest bezsensowne powinno to być podniesione na spotkaniu – ze względu na interesariuszy produktu nie ma rzeczy zbędnych. A jeżeli takie są realizowane – powinny mieć swój priorytet. 

Estimable  

Jeżeli zadanie jest zrozumiałe powinno być możliwe do oszacowania. Im mniej wiadomo – tym estymacja będzie mniej dokładna. W sytuacji gdy brakuje informacji – nie powinno dochodzić do szacowania, a zespół powinien skupić się na doszczegółowieniu wymagań. 

Small  

Zgodnie z teorią Scruma, zadaniem powinno być na tyle małe, aby dało się go zrealizować w trakcie jednego Sprinta. Lecz tak naprawdę powinno się je zrealizować w trakcie połowy tego czasu, więc jeżeli iteracje obejmują 10 dni, czas realizacji nie powinien być dłuższy niż 5. W innym przypadku zadanie powinno być podzielone na mniejsze. W sytuacji, gdy zadanie rzeczywiście zajmie więcej niż jedną iterację – powinno się stworzyć Epic, ale to opisze w innym artykule. 

Testable  

Praca oparta na jakości dla klienta powinna być możliwa do sprawdzenia. Osoba testująca nie powinna się skupiać na technicznych aspektach a jedynie sprawdzać pod kątem klienta. Techniczne aspekty, nie funkcjonalne, powinny znajdować się w Definition of “Done”. Dopiero po ich spełnieniu można zacząć testować funkcjonalne elementy. 

Podsumowanie 

Zawsze trzeba mieć na uwadze te czynniki, bo czasem traci się uwagę i powstają zadania z opisem technologicznym, za duże/skomplikowane lub ze zbyt dużą liczbą zależności. Częste przypominanie o INVEST pozwala unikać takich sytuacji i dotyczy się to każdego rodzaju zadania, nie tylko User Story.