5 powodów, dla których warto zmieniać kolejność elementów

Product Owner daje swojemu zespołowi 10 kart z historyjkami użytkownika. Członkowie zespołu czytają je i oddają Product Ownerowi kartę piątą i szóstą. Na koniec Sprintu zespół dostarcza funkcjonalności z kart 1, 2, 3, 4 i 7. Prace nad zadaniami z kart 5 i 6 nie zostały jednak jeszcze rozpoczęte.

Moim zdaniem jest to jak najbardziej w porządku.

Standardowe zalecenie w metodach zwinnych mówi, że zespół powinien pracować nad elementami Backlogu w kolejności ustalonej przez Product Ownera. Choć ma to sens do pewnego stopnia, dobre zespoły zwinne regularnie robią od tej reguły wyjątki.

Istnieje wiele dobrych powodów, dla których zespół może nie trzymać się ustalonej kolejności. Poniżej zebrałem kilka z nich, które powinny wystarczyć jako uzasadnienie:

1) Efekty synergii

Często między elementami znajdującymi się na samej górze Product Backlogu występują efekty synergii. Na przykład gdy zespół pracuje nad elementem nr 3, powinien mieć możliwość jednoczesnej pracy nad elementem nr 6. Jeśli dwa elementy dotyczą tej samej części systemu i można je szybciej ukończyć razem, Product Owner powinien na to pozwolić.

2) Zależności

Zespół może zdecydować, że element 4 jest ważniejszy niż elementy 5 i 6. Niestety, praca nad nr 4 nie może się rozpocząć, dopóki nr 7 nie zostanie ukończony. Taka zależność zazwyczaj wystarczy, by uzasadnić odejście od ustalonej kolejności.

3) Dostępność wiedzy specjalistycznej

Zespół chętnie pracowałby nad czwartym najważniejszym elementem Product Ownera, ale odpowiednia osoba jest niedostępna. Oczywiście może to być sygnał, że więcej członków zespołu powinno być w stanie pracować wielofunkcyjnie – to jednak rozwiązanie długoterminowe. Krótkoterminowo wystarczy po prostu pracować nad innymi elementami, aż potrzebna osoba będzie znów dostępna.

4) To jest ciekawsze

Okej, ten punkt można podważać. Nie twierdzę, że zespół powinien pracować nad elementami nr 1, 2, 3, 4, a potem nr 600. Ale wybór elementów jak w moim przykładzie (1, 2, 3, 4, 7) jest w porządku, jeśli dzięki temu praca staje się nieco bardziej angażująca.

W niektórych projektach zespoły natrafiają czasem na całą serię elementów Product Backlogu, które niespecjalnie sprawiają radość. Jeśli zespół może od czasu do czasu wybrać element wnoszący trochę urozmaicenia, może to pozytywnie wpłynąć na morale. A to z kolei jest korzystne dla Product Ownera.

Bonus: 4.1.) To jest ciekawsze dla interesariuszy

Skoro już jesteśmy przy tym temacie – twierdzę, że zmiana kolejności jest również uzasadniona, gdy określone elementy są interesujące dla interesariuszy.

Czasem niełatwo jest skłonić wszystkie ważne osoby do udziału w Sprint Reviews. Jest to szczególnie trudne, gdy poprzednie przeglądy były mało ekscytujące – na przykład dlatego, że priorytetowe prace były ważne, ale niezbyt widoczne dla interesariuszy.

W takiej sytuacji warto zadbać o to, by kolejny Sprint Review był bardziej atrakcyjny. Jeśli zespół pracuje nad czymś, co interesariusze uznają za ciekawe, chętniej wezmą udział w spotkaniu.

5) Rozmiar

Jeśli poprzednie powody jeszcze cię nie przekonały, zachowałem ten najbardziej przekonujący na koniec. Dowodzi on, że każdy zespół ma prawo czasem odejść od kolejności ustalonej przez Product Ownera: zespół może pominąć element nr 5, jeśli jest on zbyt duży. Wybiera wtedy kolejny element, który rozmiarem pasuje do Sprintu.

Gdyby to nie było dozwolone, zespół wybrałby tylko elementy 1, 2, 3 i 4, a następnie by się zatrzymał. W efekcie znaczna część Sprintu mogłaby pozostać niewykorzystana. Oczywiście zespół mógłby przynajmniej częściowo zrealizować element 5, a potem zabrać się za inny – jednak w wielu przypadkach nie ma to większego sensu. Dlatego zespół będzie przynajmniej od czasu do czasu odchodził od pierwotnej kolejności.

Product Ownerzy nie są idealni

Idealny Product Owner wiedziałby o tym wszystkim. Idealny Product Owner wiedziałby, że pierwsze cztery elementy w backlogu wiążą się już z tak dużą ilością pracy związanej z bazą danych, że nie powinien umieszczać kolejnego takiego elementu na pozycji 5. Idealny Product Owner wiedziałby, że elementy 2 i 5 dotyczą tej samej klasy Java i powinny być zgrupowane przy priorytetyzacji.

Większości Product Ownerów trudno jednak być idealnymi. Najlepszym rozwiązaniem jest po prostu jak najlepsze uporządkowanie Product Backlogu, a następnie pozostawienie zespołowi możliwości dopracowania szczegółów.

Ten tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.

agile100: Roger Martin

=> W lutym 2021 roku rozmawialiśmy z Rogerem L. Martinem o jego książce "When more is not Better".

Zwinne podejście w MAN

=> Jak zwinne jest MAN Truck & Bus SE i jak wygląda zwinne podejście w branży motoryzacyjnej?