Priorytyzacja i cele średnioterminowe
W innym wpisie na blogu pisałem już o tym, jak możemy przeprowadzać priorytyzację w naszym życiu prywatnym za pomocą „Teraz" i „Później". Planowane zakupy nie są kategoryzowane według pytań: Co musimy kupić? Co powinniśmy kupić? Co moglibyśmy kupić, a czego nie kupimy w ogóle? Poniżej wyjaśnię, jak można w prosty sposób wdrożyć planowanie za pomocą „Teraz" i „Później" i jednocześnie dążyć do większej wizji produktu.
Średnioterminowa wizja produktu (około trzech miesięcy) okazała się być dość sensowna. Na początku nowego kwartału Product Owner powinien wyznaczyć cel i powiedzieć: „Chcę osiągnąć ten punkt za trzy miesiące." Ta wizja jest ustalana wspólnie z zespołem i interesariuszami. Ostateczna wizja produktu pozostaje jednak wyłącznie w gestii Product Ownera.
Product Owner nie musi zbyt mocno trzymać się tej wizji – wolno ją też zmienić. Jednak bez konkretnego celu czasowego pilne tematy pojawiające się tuż przed spotkaniami Sprint Planningu szybko wpłynęłyby na priorytyzację. Bez jasnej wizji pilne tematy zawsze otrzymywałyby więcej uwagi niż tematy strategicznie ważne.
Jakie czynniki powinienem brać pod uwagę?
Kiedy muszę wybierać między różnymi pomysłami na średnioterminową wizję, lubię postępować formalnie, tak bym mógł wyjaśnić i uzasadnić swoją decyzję. Powinno się wtedy móc powiedzieć: „Zdecydowałem się skupić na tym i tamtym, zamiast na czymś innym" i przedstawić fakty, na podstawie których podjęto tę decyzję.
Jednak Product Owner musi najpierw na początku każdego Sprintu przydzielić User Stories do „Teraz" lub „Później". Pomaga to zdecydować, nad którymi elementami pracować w następnym Sprincie. Zamiast formalnego, dobrze uzasadnionego podejścia Product Owner powinien dla każdego elementu Product Backlogu brać pod uwagę następujące cztery punkty:
Jak wartościowa będzie dana funkcja
Efekt uczenia się, który pojawi się przy tej funkcji
Ryzyko związane z tą funkcją
Koszt tej funkcji
Elementy są najpierw sortowane za pomocą punktu 1, czyli według ich wartości. Do tego momentu jest to bardzo tradycyjna metoda priorytyzacji. Jednak ten nowo posortowany Backlog jest następnie porządkowany jeszcze według punktów 2–4. W zależności od tego, jak duży wpływ mają te czynniki, przesuwa się poszczególne funkcje wyżej. Ale najpierw wyjaśnię, o co chodzi z tymi czynnikami:
Drugi czynnik dotyczy tego, jak duży jest efekt uczenia się przy tworzeniu danej funkcji. Może to oznaczać na przykład, że uczy się czegoś o stosowanej technologii (coś jest trudniejsze, niż zakładano) lub stwierdza się, jak użytkownicy reagują na nowy interfejs użytkownika. Jeśli więc przez dany element Backlogu można się czegoś ważnego nauczyć, przesuwa się go w Product Backlogu wyżej, żeby mógł być rozwijany w następnym Sprincie.
W odniesieniu do ryzyka wolę rozwijać ryzykowniejsze funkcje wcześniej niż później. Wtedy można bowiem zobaczyć, jaki jest wpływ tego ryzyka. Takie elementy są więc też umieszczane w następnym Sprincie. Gdyby jednak istniała możliwość całkowitego uniknięcia ryzyka (np. przez całkowite pominięcie funkcji), element ten nie byłby umieszczany w następnym Sprincie. W najlepszym przypadku można w ten sposób postępować również w kolejnych Sprintach i tym samym całkowicie uniknąć ryzyka.
Ostatni czynnik odnosi się do kosztów. Niektóre funkcje są zazwyczaj tańsze, jeśli zostaną wykonane jak najszybciej. Stają się droższe, im dłużej są odkładane. Umieszczenie takich elementów w następnym Sprincie może utrzymać koszty na niskim poziomie.
Korzystaj z tych czterech czynników przy wyborze elementów do następnych Sprintów i stwórz średnioterminową wizję (trzy miesiące). Wtedy będziesz w stanie przeprowadzać dobrą priorytyzację „Teraz" i „Później" w dążeniu do ogólnego celu.
