.st0{fill:#FFFFFF;}

PBI, czyli Product Backlog Item 

 27 listopada, 2019

Łukasz Bręk

Czym jest Product Backlog Item? Dziś spróbuję zdefiniować, czym jest ten absolutnie podstawowy element prawie każdej zwinnej metodyki. A na pewno tych posiadających”listę rzeczy do zrobienia”, czyli backlog.

 

PBI to nic nowego

Nasz serdeczny kolega zwrócił mi kiedyś uwagę, że treści poruszane na blogu są czasem zbyt banalne. Nie zgadzam się z nim. Aby potwierdzić swoje stanowisko, postanowiłem zabrać się za dzisiejszy, nietrywialny temat.

Element Backlogu Produktu (ang. Product Backlog Item, w skrócie PBI) to nic innego, jak pojedyncze „coś” znajdujące się na liście do wykonania w naszym projekcie. To „coś” podlega wszystkim zwinnym procesom i stosowanym przez nas zasadom. I tak, w metodyce Scrum musi on posiadać atrybuty, o których wspomina Scrum Guide. PBI est także realizowany przez osoby do tego wyznaczone, czyli Zespół Developerski.

Odpowiedzialność za listę, na której znajduje się owe „coś” (patrz: backlog) należy do Product Ownera. To właśnie PO, w ramach swoich obowiązków ma za zadanie obsługę tego elementu od momentu jego pojawienia się na liście, aż do rozpoczęcia Sprint Planningu. Gdy już zostanie on zaplanowany przez Zespół Deweloperski, to możemy się spodziewać, że zostanie on zrealizowany w postaci działającego, używalnego i gotowego do wdrożenia inkrementu.

Czy powyższy opis czegoś Wam nie przypomina?

 

Product Backlog Item

Elementem Backlogu Produktu może być absolutnie wszystko. Jest to zresztą jedno z częściej zadawanych nam pytań. Nie ma bowiem znaczenia czy jest to wymaganie funkcjonalne, wymaganie niefunkcjonalne, błąd, rework funkcjonalności, życzenie naszego interesariusza, czy… No właśnie, każda z rzeczy, która dotyczy tworzonego przez nas produktu powinna być ujęta w Backlogu Produktu jako Product Backlog Item.

PBI mogą być zapisywane w postaci User Story, Use Case, zadań czy w innej, dowolnej postaci posiadającej nagłówek oraz opis elementu. Jaką metodę wybierzemy? Nie ma to znaczenia, zespoły są samoorganizujące się. Ważne, żebyśmy dobrze się czuli z wybranym formatem i aby w każdej chwili wszyscy zaangażowani w projekt mogli sprawdzić, co mamy do zrobienia.

Przewodnik po Scrum w żadnym miejscu nie namawia, aby wykorzystać jakąkolwiek technikę. Te wspominane wyżej one po prostu dobrymi praktykami, natomiast nasz projekt możemy prowadzić tak, jak nam się podoba.

 

PBI vs US vs SPI

Nie da się ukryć, że zwinny świat wykorzystuje wiele mniej lub bardziej sugestywnych skrótów. Spróbujmy odpowiedzieć na pytanie, jak ma się Element Backlogu Produktu do US (ang. User Story) oraz SBI (ang. Sprint Backlog Item).

PBI może być, choć nie musi zapisany w postaci User Story. Historyjka użytkownika posiada określaną strukturę i wymaga, aby konkretne, zgłoszone przez naszego klienta wymaganie zostało zapisane we właściwy sposób. Możemy więc powiedzieć, że każde User Story to PBI, ale nie każdy element Backlogu Produktu to User Story.

Sprint Backlog Item (SPI) to te PBI, które Zespół Deweloperski prognozuje, że wykona w bieżącej iteracji. Cykl życia wymagania może spowodować (i często tak właśnie jest), że na jedno PBI przypada wiele SBI. Jest to konsekwencją pracy nad wymaganiem na przykład podczas Product Backlog Refinementu i wydzieleniem z niego możliwych do realizacji podczas pojedynczego Sprintu części. Zdarza się też tak, że na jeden PBI będzie przypadał dokładnie jeden SBI. To znaczy, że na Planowaniu Sprintu po prostu przenosimy Element Backlogu Produktu do Backlogu Sprintu.

Proste?

 

Podstawy Product Backlog Item

Ten post jest odpowiedzią na potrzeby osób, które odwiedzają nasz #białkowy blog. Wiele z nich wprost szuka odpowiedzi na pytanie „Czym jest PBI?”. Dla części osób, tych doświadczonych w wykorzystaniu chociażby metodyki Scrum, jest to chleb powszedni, podstawa podstaw i część scrumowego rzemiosła. Dla innych, szczególnie tych „siłą” wcielonych w metodykę i postawionych przez faktem dokonanym, termin zupełnie nieznany. Mam nadzieję, że zarówno jedni jak i drudzy wyniosą z tego krótkiego wpisu garść przydatnych informacji.

Na co dzień nie posługujemy się terminem PBI. Jesteśmy „ofiarami” tłumaczenia Scrum Guide na język polski. Naturalnie powoduje to, że nie posługujemy się tym terminem, ale mówimy „Element Backlogu Produktu”, którego wcale nie skracamy do „EBP”. Sam zostałem ostatnio zaskoczony użyciem „PBI” przez uczestnika jednego ze szkoleń Scrum. Naprawdę się tego nie spodziewałem!

Analizując to, czego szukacie na stronach naszego #białkowego bloga coraz częściej dochodzimy do wniosku, że istnieje potrzeba stworzenia zwinnego słownika. Będzie to miejsce, które będzie grupowało wszystkie te trzyliterowe (i dłuższe oczywiście też) skróty. Co więcej, świetnie będzie to wpisywało się w naszą misję! Zarówno ja jak i Tomek jesteśmy urodzonymi Scrum Masterami odpowiedzialnymi za rozumienie i stosowanie metodyki, jaką jest Scrum.

 

PS. Pozdrowienia dla serdecznego kolegi, z którym widziałem się w ostatni piątek. Stwierdził, że jest już „duuuużo lepiej”.

Łukasz Bręk


15 lat doświadczenia w IT, 8 lat doświadczenia w metodykach zwinnych, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy/systemowy, Agile Coach, trener Scrum.
Swój warsztat szlifował na projektach waterfallowych, dziś skupiony wokół zwinnego dostarczania Produktu.

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}