Nie wszystkie elementy w backlogu produktu będą miały tę samą wielkość i poziom szczegółowości w tym samym czasie (tj. funkcje / epiki / historie użytkowników i zadania). PBIs, nad którymi planujemy pracować wkrótce, powinny znajdować się blisko góry backlogu, być małe i bardzo szczegółowe, aby mogły być realizowane w nadchodzącym sprincie. PBIs, nad którymi nie będziemy pracować przez jakiś czas, powinny znajdować się na dole backlogu, być większe i mniej szczegółowe.
Przypadki użycia / Funkcjesą to możliwości, które będą miały Twoje końcowe użytkownicy, których wcześniej nie mieli. Na przykład, zakup przedmiotów online za pośrednictwem telefonu komórkowego byłby funkcją. Twoja mapa drogowa produktu zazwyczaj składa się z wymagań na poziomie funkcji.
Epiki są następnym etapem w rozkładaniu funkcji na wykonalne wymagania. Są to szereg działań związanych z funkcją. Możliwość zakupu przedmiotu za pośrednictwem telefonu komórkowego z koszyka zakupowego przy użyciu karty kredytowej byłaby epikiem. Jest mniejsza niż funkcja (zakup przedmiotu online), ale większa niż pojedyncze integracje kart kredytowych, które umożliwiają zakup przedmiotu. Nie dopuszczamy wymagań większych niż epiki do planu wydania.
Historie użytkowników są najmniejszymi formami wymagań, które mogą nadal funkcjonować samodzielnie. Historia użytkownika składa się z jednej akcji wartości lub jednej integracji wartości. Na przykład, zakup przedmiotu za pośrednictwem telefonu komórkowego z koszyka zakupowego przy użyciu karty Visa byłby historią użytkownika. Zakup przedmiotu przy użyciu karty MasterCard mógłby być inną integracją, a zatem inną historią użytkownika. Historie użytkowników są wystarczająco małe, aby dodać je do sprintów i rozpocząć rozwój. Szczegółowo omawiam historie użytkowników w kolejnych sekcjach.
Zadania są wewnętrznymi krokami potrzebnymi do wdrożenia historii użytkownika. Podczas planowania sprintu historia użytkownika jest rozkładana na zadania. Podczas gdy wymagania to rzeczy, które wykonuje końcowy użytkownik, zadania to to, co zespół deweloperski robi, aby wymóg działał.
Poziom szczegółowości elementów backlogu produktu (PBI)
Rysunek przedstawia różne warstwy dekompozycji wymagań, aby dopasować się do serii sprintów na mapie drogowej rozwoju.
- Na górze tego rysunku znajdują się pomarańczowe, największe cegły. Reprezentują one cele biznesowe, które mają być osiągnięte przez system, a mianowicie przypadki użycia lub funkcje użytkowników.
- Na następnym poziomie znajdują się PBI, które są większe niż pojedynczy sprint, ale mniejsze niż wydanie. Nazwijmy PBI na tym poziomie epikami.
- Na trzecim poziomie znajdujemy PBI, które są odpowiednio dopasowane do sprintu – mogą być ukończone w ciągu dni, a nie tygodni. Te elementy spełniają Definicja Gotowości i mogą być reprezentowane jako historie użytkowników.
- Na najniższym poziomie te PBI mogą opcjonalnie być rozkładane na zadania z historii użytkowników i dostarczane do końca jednej iteracji.
Backlog produktu
Backlog produktu wymienia wszelkie wymagane dostawy. Jego zawartość jest uporządkowana według wartości biznesowej. Jak wspomniano powyżej, najważniejsze elementy są pokazane na górze backlogu produktu, aby zespół wiedział, co dostarczyć jako pierwsze. Priorytet elementów backlogu może się zmieniać, wymagania mogą być dodawane i usuwane – dlatego backlog produktu jest ciągle utrzymywanym planem w kierunku rosnącej wartości biznesowej.
Elementy backlogu produktu
Elementy backlogu produktu (PBI) to elementy, które składają się na backlog produktu. Elementy backlogu produktu mogą obejmować specyfikacje i wymagania, przypadki użycia, epiki, historie użytkowników, a nawet błędy, lub ograniczone czasowo zadania badawcze.
Proces planowania sprintu
Planowanie sprintujest często potrzebne, aby zapewnić, że backlog produktu został udoskonalony do odpowiedniego poziomu szczegółowości, z oszacowaniami i kryteria akceptacji (to jest cel udoskonalenia backlogu produktu). Jeśli elementy backlogu produktu zostały przeanalizowane i przemyślane podczas procesu udoskonalania backlogu produktu, na spotkaniu planowania sprintu elementy backlogu produktu o najwyższym priorytecie mogą być dobrze zrozumiane i łatwo wybrane.
Podsumowanie
Celem procesu udoskonalenia backlogu produktu jest przygotowanie elementów backlogu produktu do stanu gotowości do planowania sprintu, aby elementy backlogu produktu były:
- Na tyle jasne i zrozumiałe dla wszystkich w zespole
- Na tyle małe, aby mogły być uwzględnione w sprincie
Inne polecane artykuły o Scrumie
- Czym są artefakty Scrum?
- Czym jest Definicja Gotowości w Scrum?
- Jak napisać cel sprintu?
- Czym jest backlog produktu w Scrum? Kto jest za niego odpowiedzialny?
- Jak udoskonalić backlog produktu?
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文