Pielęgnacja Backlogu Produktu to jedno z podstawowych zadań Product Ownera. Do zadań związanych z pielęgnacją należy dopisywanie nowych User Stories w miarę ich formułowania i uszczegóławiania. Najważniejszym z zabiegów pielęgnacyjnych jest jednak dbanie o właściwą kolejność wpisów zamieszczaonych w Backlogu Produktu, czyli o priorytetyzację zadań.

Jak przeprowadzić pielęgnację backlogu produktu – omówione zagadnienia:

  1. Wprowadzenie
  2. Pielęgnacja Backlogu Produktu – w jakim celu?
  3. Błędy w pięlęgnacji Backlogu Produktu
  4. Pielęgnacja Backlogu a metryki stosowane w Scrum
  5. Podsumowanie

Wprowadzenie

Product Backlog to jeden z Artefaktów Scruma. Zawiera on uporządkowaną według priorytetów listę prac potrzebnych do stworzenia Produktu. Innymi słowy, jest listą User Stories niezbędnych do realizacji Celu Produktu. Dokładny opis tego, czym są User Stories, znajduje się w tym artykule. Tutaj natomiast znajdują się szczegóły dotyczące charakterystyki i sposobów prowadzenia Backlogu Produktu.

Pielęgnacja Backlogu Produktu jest również znana pod nazwami:

  • Priorytetyzacja Backlogu,
  • Doskonalenie Backlogu, a także
  • Skalowanie Backlogu.

Pielęgnacja Backlogu Produktu – w jakim celu?

Product Backlog jest zarządzany przez Product Ownera, do którego kluczowych umiejętności należy priorytetyzacja zadań w miarę zbliżania się terminu ich realizacji. Celem pielęgnacji Backlogu Produktu jest bowiem upewnienie się, że na samej górze listy zadań do wykonania znajdują się funkcjonalności Produktu o największej wartości biznesowej, czyli te najważniejsze z punktu widzenia Klienta. Oraz że są one opisane jasno i szczegółowo, tak, aby ich realizacja mogła rozpocząć się już w kolejnym Sprincie.

Backlog Produktu może być aktualizowany nawet codziennie, jeśli jest taka potrzeba. Product Owner może dopisywać do Backlogu Produktu nowe User Stories po rozmowie z Interesariuszami, Zespołem Developerskim, lub wyciągając wnioski i przeformułowując User Stories już wpisane w Backlog Produktu.

Obowiązkowa aktualizacja Backlogu to jedno z zadań wykonywanych podczas Sprint Review. Jego przebieg szczegółowo opisujemy w tym artykule. Zwykle podczas tego spotkania Scrum Team omawia nie tylko zadania przeznaczone do realizacji w następnym Sprincie. Uszczegóławia także wstępnie User Stories, które będą realizowane w następnych dwóch lub trzech Sprintach. Taki sposób działania pozwala na szersze spojrzenie na długofalowy kierunek rozwoju Scrum Team i jego działań. Dzięki temu może on myśleć o aktualnie wykonywanych zadaniach w perspektywie ich rozwinięcia w kolejnych Sprintach.

Błędy w pięlęgnacji Backlogu Produktu

Jednym z najczęstszych problemów dotyczących pielęgnacji Backlogu Produktu jest dopuszczenie do niekontrolowanego poszerzania się jego zakresu. Podczas pracy nad Produktem pojawiają się bowiem spontanicznie różne dodatkowe funkcjonalności i zadania proponowane zarówno przez Interesariuszy jak i członków Scrum Team. Dlatego ograniczanie rozrastania się zakresu Backlogu Produktu (tzw. scope creep) to jedno z najważniejszych zadań wykonywanych przez Product Ownera. Do najczęstszych błędów, których poprawieniem zajmuje się Product Owner należą:

  1. Odbieganie od Celu Produktu– dopisywanie do Backlogu Produktu zbyt wielu pomysłów wykraczających poza podstawowy Cel Produktu nie jest dobrą praktyką, ponieważ bardzo obniża to jego czytelność. Zdecydowanie lepiej sprawdza się zbieranie pomysłów na dodatkowe funkcjonalności w osobnym dokumencie.
  2. Zwielokrotnienie treści– wpisywanie do Backlogu powtarzających się lub bardzo podobnych do siebie idei pochodzących od różnych Interesariuszy – przed dodaniem kolejnego wpisu do Backlogu, Product Owner powinien upewnić się, czy nowy wpis nie duplikuje któregoś z już istniejących.
  3. Brak szerszej perspektywy– wpisy w Backlogu Produktu powinny być uporządkowane zgodnie z ich wartością w odniesieniu do Celu Produktu, jednak priorytetyzacja powinna uwzględniać kilka następnych Sprintów, tak aby zadania realizowane w danym Sprincie były płynnie powiązane zarówno z poprzedzającym, jak i Sprincie następującym bezpośrednio po nim.

Błędów tego typu nie sposób uniknąć. Jednak świadomość ich pojawiania się może sprawić, że Product Owner będzie ostrożniej dopisywał nowe User Stories do Backlogu Produktu. Musi on wypracować odpowiednią równowagę. Błędem jest bowiem również zbytnie okrajanie Backlogu i eliminacja wpisów, które zawierają podobne zadania różniące się jednak istotnymi kwestiami. Na przykład opisujące podobne funkcjonalności Produktu, które istotnie różnią się zastosowaniem.

Pielęgnacja Backlogu a metryki stosowane w Scrum

Backlog Produktu zawieraja opis pracy, która pozostała do wykonania w całym projekcie. Jednak jedynie aktualny i regularnie pielęgnowany Backlog pozwala trafnie szacować stosunek ilości wykonanej pracy do jej całości. Do obrazowania ilości zakończonej pracy, używany jest Wykres Spalania (Burndown Chart), o którym pisaliśmy w tym artykule.

Innym wskaźnikiem, często używanym do opisywania pracy Scrum Team jest Velocity (Prędkość). Mierzy się ją przez porównanie ilości wpisów w Backlogu Produktu przekształconych w Przyrost podczas jednego Sprintu. Velocity opisujemy bardziej szczegółowo w tym artykule.

Pielęgnacja Backlogu Produktu

Podsumowanie

Pielęgnacja Backlogu Produktu to zadanie wykonywane przez Product Ownera. Gdy Backlog Produktu jest dobrze prowadzony, Scrum Team ma jasny obraz pracy, która pozostała do wykonania. Może również uzyskać szerszy, perspektywiczny obraz, jak wygląda ścieżka prowadząca do realizacji Celu Produktu. Dlatego właśnie Product Owner musi dbać o to, by User Stories zawarte w Backlogu Produktu były uporządkowane według priorytetu ich wykonania. A także, żeby zadania przeznaczone do wykonania w najbliższych Sprintach były opisane najbardziej szczegółowo.

Pielęgnacja Backlogu Produktu to jeden z kluczowych elementów pracy Product Ownera, o pozostałych przeczytasz w naszm poprzednim artykule: Kim jest Product Owner?

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 40. Jak przeprowadzić pielęgnację backlogu produktu? caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?