4

W ostatniej edycji kursu internetowego, który prowadzę Scrum Assistance pojawiła się bardzo ciekawa dyskusja, związana z tematem historyjek użytkownika i wartości biznesowej.

W ramach dyskusji pod jedną z kolejnych lekcji kursu, pojawił się ciekawy wpis i pytanie:

To jest bardzo ciekawy wątek, który chciałbym wykorzystać do podzielenia się z Wami kilkoma przemyśleniami na temat posługiwania się pojęciem „wartości biznesowej” w naszych sprintach.

Czy każda historyjka ma wartość biznesową?

Obserwując różnego rodzaju projekty, w których uczestniczę coraz częściej dochodzę do wniosku, że pojęcie „wartości biznesowej” jest w wielu zespołach scrumowych nagminnie nadużywane.

Zresztą doskonałym przykładem, który to potwierdza – jest wpis mojej kursantki, który wcześniej przytoczyłem:

„Głównym problemem w naszej firmie jest przyjęta definicja user story i to, że każda user story ma mieć wartość biznesową”.

No, dobrze. Czy faktycznie każda historyjka użytkownika, która trafi do sprintu powinna mieć wartość biznesową?

Moja odpowiedź, brzmi: NIE. Wiem, że być może narażę się tu wielu osobom, ale dla historyjek, które trafiają do Backlogu Sprintu, tak naprawdę trudno jest określić wartość biznesową.

I nie ma absolutnie żadnego znaczenia, czy jest to historyjka typowo funkcjonalna, czy techniczna. Historyjki, które trafiają do sprintów – nie mają wartości biznesowej.

Wiem, że w wielu naszych firmach jest duże ciśnienie, żeby wszystkie historyki w sprintach miały charakter „biznesowy”, ale to jest pewna iluzja, którą zdecydowanie Wam odradzam.

Hedoniczny model cen

W ekonomii jest taka koncepcja, która tak groźnie się nazywa – „hedoniczny model cen”. Została po raz pierwszy wykorzystana do tego, żeby wyjaśnić różnice w cenach rynkowych win.

Postawiono hipotezę, że na wartość wina wpływa wiele czynników. Należą do nich: jego smak, zapach, kolor itd. I, co ważne, te czynniki, same w sobie nie mają
szansy stać się przedmiotem zainteresowania konsumenta. Z kolei, z takiej szansy korzysta już wino, którego wartość określa właśnie suma

wspominanych czynników.

I to jest koncepcja, która jest również wykorzystywana do wyceny mieszkań. Zauważcie, że jeżeli kupujecie mieszkanie, to na jego cenę wpływa kilka czynników. Pierwsza grupa, to tzw. „czynniki wewnętrzne” – metraż, wygląd, wyposażenie, wykończenie. A druga, to „czynniki zewnętrzne” – np. jak daleko jest najbliższe przedszkole czy szkoła, jakość powietrza, ceny innych nieruchomości w okolicy itd.

Dla was jako kupujących, same te czynniki, bez odniesienia do mieszkania, nie mają większego znaczenia. Dopiero ich suma, zaczyna dla Was coś znaczyć.

I bardzo podobnie jest z wartością biznesową w naszych sprintach.

Kiedy mówienie o wartości biznesowej ma sens?

Historyjki użytkownika, które trafiają do sprintów są tylko jednym z czynników, określających wartość większej całości.

Dlatego, mówienie o wartości biznesowej ma sens, tylko w przypadku dużych historyjek użytkownika, a więc epików. A te są za duże, żeby zespoły mogły je zrealizować w sprincie. O epikach mówimy raczej w kontekście konkretnych wydań produktu czy punktów milowych projektu, ale nie konkretnych sprintów.

Podobnie, mówienie o wartości biznesowej ma sens w kontekście tematów, które są zbiorem konkretnych epików, powiązanych ze sobą jednym, wspólnym wątkiem.

Mając to wszystko na uwadze, przypisywanie wartości biznesowej do konkretnej historyjki użytkownika, która trafia do Backlogu Sprintu – trochę mija się z celem. I jest tylko niepotrzebnym nadużyciem, które prowadzi do niepotrzebnych nieporozumień w naszych firmowej rzeczywistości.

Co z historyjkami technicznymi w sprincie?

Wiem, że ogromna większość Product Ownerów nie widzi najmniejszego sensu w realizacji zadań technicznych w sprintach. Bo są dla nich „bezwartościowe”.

To w dużej mierze wynika z tego, że większość z nich nie jest osobami technicznymi. I liczy się dla nich tylko perspektywa biznesowa. Oczywiście nie ma w tym nic złego – reprezentują przecież biznes i zależy im po prostu na rozwoju nowych funkcjonalności.

Co jednak nie zmienia faktu, że historyjki techniczne powinny być pełnoprawną częścią backlogu, podobnie jak błędy czy zadania badawcze.

Jeżeli Wasi Product Ownerzy tego nie czują, to jest tutaj duże pole do popisu dla Waszych Scrum Masterów, którzy powinni czuwać nad Scrumem w firmie i skupić się na wykształceniu odpowiedniego poziomu świadomości wśród Product Ownerów, z którymi macie okazję pracować.

Czy deweloper powinien „odbierać” historyjki techniczne?

Na koniec, nawiążę jeszcze krótko do pomysłu „odbierania” historyjek przez deweloperów w sprincie.

To jest rzecz, którą zdecydowanie Wam odradzam. Product Owner powinien być i czuć się właścicielem wszystkich historyjek, które trafiają do Backlogu Produktu, także historyjek technicznych.

Jeśli go z tego obowiązku „zwolnicie”, to wcześniej czy później pojawi się pewna schizofrenia w zarządzaniu Backlogiem Produktu, „Historyjki funkcjonalne są moje, a reszta jest Wasza”.

Natomiast, w przypadku historyjek technicznych, bardzo ważne jest to, jak taką historyjkę można pokazać na przeglądzie sprintu. Co będzie ciekawe dla Product Ownera? Wcale nie musicie pokazywać mu kodu. Ale to już jest temat na osobną historię 😉