.st0{fill:#FFFFFF;}

PBI, czyli Product Backlog Item 

 27 listopada, 2019

Tomasz Dzierżek

PBI (Product Backlog Item) jest skrótem, którego nie znajdziecie w Scrum Guide. Jest on jednak popularny w środowisku i występuje w wielu różnych materiałach, szczególnie po angielsku. Postanowiłem więc wyjaśnić jego znaczenie.

 

PBI, czyli Element Backlogu Produktu

PBI to znaczy Product Backlog Item. Po polsku zaś tłumaczymy to jako Element Backlogu Produktu, ale żadnego skrótu raczej nie stosujemy. Product Backlog Item to sformułowanie, które oznacza każdy jeden element na liście wymagań, potrzeb, marzeń i rzecz do zrobienia zwanej Product Backlogiem.

Zakładam, że dobrze wiemy, czym jest backlog. Jeśli nie, to szybkie przypomnienie. Product Backlog to lista rzeczy do zrobienia w ramach naszego produktu, uporządkowana przez Product Ownera od najważniejszych (tych, które będą realizowane w pierwszej kolejności) do mniej ważnych (i zostawionych na później). Nietrudno nam więc sobie wyobrazić, czym jest element tej listy.

Niezależnie od tego czy jest to duży element (jak Epic) czy mniejszy (jak poszczególne wymaganie czy User Story), czy też mówimy o błędzie do poprawy albo jakikolwiek zidentyfikowanej rzeczy do zrobienia – wszystko to będzie PBI, czyli Elementem Backlogu Produktu.

 

Cechy Product Backlog Item

PBI nie ma żadnych sformalizowanych wymagań. Nie musi być w żadnym konkretnym formacie, ani nie musi mieć żadnych cech. PBI to po prostu jedna dowolna rzecz do zrobienia w ramach rozwoju naszego produktu. Innymi słowy, Product Backlog Item to jakiś kawałek pracy, który jest opisany w sposób przyjęty w naszym zespole.

Oczywiście Elementy Backlogu Produktu mają pewne cechy wynikające z samego bycia częścią backlogu. To znaczy, PBI na szczycie listy prawdopodobnie będą mniejsze, precyzyjniej określone i gotowe do realizacji. Te, które znajdują się gdzieś dalej w backlogu, częściej będą życzeniami, marzeniami czy luźnymi notatkami. Na pewno fajnie by było, aby nasze PBI były też w jakiś sposób oszacowane, żebyśmy wiedzieli, czy są duże czy małe.

Jeżeli chcemy być szczególarzami, to możemy przyjąć, że każdy PBI powinien mieścić się w Sprincie i dostarczać jakąkolwiek wartość biznesową. To znaczy, po zrealizowaniu danego Elementu Backlogu Produktu nasz produkt powinien być lepszy. Pamiętajmy jednak, że PBI to nie zadanie do wykonania (np. napisanie kodu, przeprowadzenie testów), ale jakieś wymaganie czy potrzeba biznesowa.

 

Product Backlog Item to nie tylko „wymaganie”

Wiele osób utożsamia PBI z wymaganiami. Ci bardziej doświadczeni powiedzą, że Product Backlog Item to może być też błąd do poprawy. To już sugeruje, że sprawa nie jest taka prosta. Tym bardziej, że na tych dwóch elementach lista się nie kończy.

Każdy biznesowo zamknięty kawałek pracy, który można określić jako „trzeba zrobić to i to”, to może być PBI. Powtórzmy to jeszcze raz: PBI to nie indywidualne zadania, ale wymagania bądź potrzeby biznesowe. Każde powinno coś wnosić, nawet kiedy zrealizujemy je same.

Product Backlog Item może być User Story, Use Casem, raportem z błędów, zgłoszeniem od klienta, diagramem procesu do zaimplementowania, itd., itp. Niestety, za często ludzie skupiają się na formacie zapisu PBI, a nie na jego istocie.

 

PBI kontra User Story

Na koniec warto więc odczarować jeszcze jedną rzecz. Tak jak wiele osób utożsamia Product Backlog Item z „wymaganiem”, tak podobna grupa osób będzie twierdziła, że to są po prostu „User Story”. Nie jest to prawdą.

User Story to bardzo konkretny i specyficzny sposób zapisu wymagań. Rządzi się swoimi prawami i ma określone zasady. Jakoś się też złożyło, że jest to najczęściej używany sposób zapisu wymagań w zwinnych backlogach. Nic więc dziwnego, że łatwo o pomyłkę.

Wcale nie jest powiedziane, że PBI muszą być zapisywane w formacie User Stories. Aczkolwiek w świetle tego co wiemy, trzeba przyznać, że jak najbardziej pasuje on do koncepcji Product Backlog Item. I jedno, i drugie precyzuje nam jakąś wartościową potrzebę biznesową, która po zrealizowaniu sprawi, że nasz produkt będzie lepszy. Nie warto jednak mylić US-ów z Elementami Backlogu Produktu.

Jeżeli jesteś zainteresowany tematem User Stories, mamy na ten temat osobny tekst, a także prowadzimy warsztaty i szkolenia nastawione na pisanie User Stories. Zapraszamy!

Tomasz Dzierżek


18 lat doświadczenia w IT, 10 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

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"}